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Preface 


This  thesis  is  dedicated  to  the  memory  of  my  father, 
Raymond  Oliver  Solander  (26  November  1917  to  27  October 
1982). 

Robotics  is  a  rapidly  growing  field.  Interest  has  grown 
worldwide  as  well  as  within  the  Department  of  Defense.  This 
project  deals  with  an  extension  of  robotics:  a  very 
sophisticated  mechanism  termed,  herein,  an  android. 
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Abstract 


This  report  identifies  areas  requiring  further  research 
to  develop  a  detailed  research  and  development  plan  for  an 
aircraft  maintenance  android.  The  general  user  requirements 
are  defined  and  the  desired  android  capabilities  are 
addressed  to  meet  the  defined  user  requirements.  The  user 
requirements  are  defined  independently  of  aircraft  type. 
Structured  analysis  diagrams  are  used  to  describe  the 
functional  requirements.  Specific  recommendations  are  made. 


AN  ANDROID  RESEARCH  AND  DEVELOPMENT  PROGRAM 


I.  Introduction 


Background 

Robots  and  androids  bring  varied  images  and  definitions 
to  mind.  Some  of  these  images  and  definitions  stem  from 
fictional  literature  associations,  others  from  practical 
involvement  with  industry.  The  history  and  definitions 
presented  in  the  background  section  of  this  introduction 
provide  a  common  basis  of  knowledge  between  the  author  and 
the  readers.  The  remaining  sections  of  the  introduction 
provide  a  transition  from  these  definitions  and  history  into 
the  work  accomplished  by  this  thesis. 

Joseph  F.  Engelberger,  president  and  founder  of 
Unimation,  Inc.  (of  Danbury,  Connecticut,  the  first  U.S. 
robot  manufacturer),  claimed  his  interest  in  robots  started 
in  the  1940s  while  an  undergraduate  physics-major  at 
Columbia  University.  He  read  the  robot  stories  of  his 
fellow  Columbian,  Isaac  Asimov  (Asimov,  1982a:  xiii).  Many 
of  us  can  say  the  same  thing — our  interest  in  a  particular 
scientific  area  (robots  for  example)  stemmed  from  reading 


the  fiction  and  speculations  of  others.  It  is  easy,  once 
the  imagination  is  captured,  to  expend  energy  and  effort  to 
see  if  our  dreams  can  be  realized. 

Asimov  and  robots  are  almos'  always  thought  of  together; 
however,  Isaac  Asimov  did  not  write  the  first  robot  story. 
In  1942,  he  did  invent  the  term  'robotics'.  The  robots  he 
envisioned  were  more  like  the  'industrial  robots’  of 
today — manipulators  "created  by  engineers  to  do  specific 
jobs  and  with  safety  features  built  in  (Asimov,  1982a: 
xiii)".  The  first  story  about  a  robot  (although  not  called 
a  robot)  was  mentioned  in  legend — during  the  Middle  Ages! 
This  was  the  Golem,  brought  to  life  by  Rabbi  Loew  of  Prague 
in  the  Middle  Ages.  This  robot  was  formed  of  clay  (Asimov, 
1982a:  57;  Raphael,  1976:  253). 

Karel  Capek's  play  'R.U.R. ',  introduced  the  term 
'robot'  to  the  world  in  1920.  But  it  did  not 
involve  robots  in  the  strictest  sense  of  the  word. 

The  robots  manufactured  by  Rossum’s  Universal  Robots 
(the  'R.U.R.'  of  the  title)  were  androids  (Asimov, 
1982a:  153). 

So  much  for  the  past  of  robots  and  robotics;  but  where 
are  they  now? 

Portia  Isaacson  predicts  that  we  will  soon  see 
robot  stores  in  addition  to  our  current  computer 
stores  and  software  stores .. .Jerome  Hamlin 
constructed  a  robot  'butler'  at  home.  He  named  it 
Comro  I  and  persuaded  Neiman-Marcus  to  feature  the 
robot,  priced  at  $15,000,  in  its  [1981]  Christmas 
catalog.  The  store  sold  three.  Hamlin  is  now 
working  on  a  robot  kit  that  he  plans  to  sell  for 
under  $2000.  Heath  has  already  demonstrated  a 
prototype  robot  kit  that  it  plans  to  introduce 
either  later  this  year  or  next  year  for  between 
$1500  and  $3000.  Several  companies  are  already 
selling  computer  controlled  arms  and  bodies  in  kit 
form  that  range  in  price  from  $700  to  $2500,  and 
there  are  rumors  that  some  toy  companies  have 
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developed  prototypes  of  true  robotic  toys  that  will 
sell  in  the  §300  to  §500  price  range.  So  far,  the 
personal  robotics  products  and  projects  that  have 
been  built  are  awkward  and  not  very  useful, 
reminiscent  of  the  early  personal  computers.  But 
more  and  more  experimenters  are  getting  involved  in 
robotics  projects,  and  the  likelihood  is  that  we 
will  soon  see  the  fruits  of  these  labors  translated 
into  a  mushrooming  new  market  (Libes,  1982:  446, 
449). 

With  predictions  of  robot  stores  and  promises  of  robot  kits 
both  by  individuals  and  companies,  it  appears  that  robots 
have  caught  the  imagination  and  the  minds  of  laymen.  But 
currently,  the  people  who  have  the  largest  demand  for  robots 
are  the  industrialists. 

Industry,  however,  has  its  own  definition  of  a  robot. 
Jack  Lohr,  the  vice-president  of  Robotics  International, 
provided  an  official  industry  definition: 

A  robot  is  a  reprogrammable  multifunctional 
manipulator  designed  to  move  material,  parts,  tools, 
or  special  devices,  through  variable  programmed 
motions  for  the  performance  of  a  variety  of  tasks 
(Seminar,  1982). 

Industry  first  used  industrial  robots  (built  by  Unimation, 
Inc.)  for  die  casting  in  the  1960s  (Calahan,  1982:  130).  So 
far,  industry  is  the  largest  robotics  user,  with  the 
automotive  industry  as  the  largest  single  user  (Freedman, 
1982).  As  such,  research  and  development  has  been  conducted 
primarily  to  meet  industry’s  needs.  Since  industry  provided 
the  funding  and  impetus  for  the  research,  that  is  only 
natural . 

However,  "the  Pentagon  is  calling  for  a  supportive  role 
fostering  the  U.S.  development  of  robotics  technology 
(Military,  1982:  4).”  With  this  increased  Department  of 
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Defense  (DOD)  interest  in  robotics,  an  evaluation  of  where, 
how,  and  what  impact  robots  will  have  on  DOD  is  necessary. 
A  very  brief  overview  of  the  DOD  Research  Program  in 
Robotics  was  published  in  1980.  This  overview  included  the 
future,  as  well  as  the  present,  impact  of  robots  on  DOD. 

DOD  has  all  of  the  cost/productivity/worker 
morale  problems  of  industry  plus  a  few  speci al 
problems  of  its  own.  Not  only  must  DOD  manufacture 
systems,  it  must  also  support  and  maintain  these 
systems  across  a  far-flung  theater  of  operations  in 
frequently  hostile  operating  environments,  using  a 
largely  unskilled  labor  force  that  has  a  high 
turnover  rate.  Thus,  the  demand  for  intelligent, 
flexible  automation  (robots)  is  obvious ....  Robots 
will  be  developed  for  DOD  field  uses  to  assist 
combat  and  support  forces.  These  field  applications 
will  place  still  greater  requirements  on  robots  to 
be  more  flexible,  intelligent  and  to  have  sensory 
capabilities  (Vranish,  1980:  5,  7). 

In  fact,  with  the  variety  of  possible  DOD  applications, 

several  classes  or  kinds  of  robots  to  meet  these  needs  would 

probably  be  most  advantageous.  This  thesis  does  not  deal 

with  an  overall  DOD  evaluation  and  research  recommendation, 

but  with  one  particular  goal  of  interest  to  the  United 

States  Air  Force  (USAF). 

This  goal  was  described  by  Dr.  Ints  Kaleps,  Branch  Chief 
of  the  Mathematics  and  Analysis  Branch  of  the  Air  Force 
Aerospace  Medical  Research  Laboratory  ( AFAMRL ) ,  in  August 
1981.  This  goal  was 

a  robot  capable  of  repairing  and  refueling  aircraft 
in  a  hostile  environment  without  direct  human 
intervention  or  supervision  (Kaleps,  1981a). 

'Hostile  environment’  included  space  and  hazardous 

radioactive  or  chemical  areas.  In  September  1981,  he  also 

expressed  a  need  for  a  systematic  definition  of 
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robotic  research  intitiatives  with  applications  to 
the  Air  Force  and  particularly  the  AFAMRL  missions 
(Kaleps,  1981b). 

To  meet  the  need  for  a  systematic  definition  of  robotic 
research  initiatives,  AFAMRL  sponsored  and  supported  this 
thesis. 

This  thesis  defines  a  set  of  robotic  research 
initiatives  which  if  followed,  implemented,  and  carried 
through  to  some  natural  conclusion,  could  result  in  a  robot 
capable  of  repairing  and  refueling  aircraft  in  a  hostile 
environment  without  direct  human  intervention  or 
supervision.  The  required  technology  to  construct  such  a 
robot  does  not  presently  exist.  Research  continues  on  the 
various  components,  such  as  artificial  intelligence, 
manipulators,  sensors,  controls,  and  pattern  recognition. 
Unfortunately,  according  to  Feldman,  little  or  no 
communication  has  occured  among  researchers  in  these 
separate  areas  (Feldman,  1980:  244). 

Problem  and  Scope 

Definitions.  Not  only  has  communication  among  the 
different  research  areas  been  limited,  but  no  standard  set 
of  definitions  has  existed  (Weinstein,  1980:  37;  Seminar, 
1982).  So  far,  in  this  thesis,  the  term  robot  has  been  used 
rather  loosely.  This  term  has  been  commonly  and  easily 
recognized  by  scientists  and  laymen  alike.  However,  many 
definitions  of  'robot'  exist,  all  of  which  are  dependent 
upon  who  does  the  defining.  Since  neither  scientists,  nor 
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the  dictionary  (representing  laymen)  can  agree  on  a  standard 
definition  of  robot,  the  following  definitions  will  be  used 
in  this  thesis: 


1.  An  'industrial  robot'  is  a  [mechanized,] 
reprogrammable  multifunctional  manipulator  designed 
to  move  material,  parts,  tools,  or  specialized 
devices,  through  variable  programmed  motions  for  the 
performance  of  a  variety  of  tasks  (Seminar,  1982). 

2.  A  'robot'  is  a  mechanism,  fixed  or  mobile, 

possessing  the  ability  to  manipulate  objects 
external  to  itself  under  the  constant  control  of  a 
human  being,  a  computer,  or  some  other  external 
intelligence  (Weinstein,  1980:  37). 

3.  An  'android'  is  a  mobile  mechanism  possessing 

the  ability  to  manipulate  objects  external  to  itself 
under  the  constant  control  of  its  own  resident 
intelligence,  operating  within  guidelines  initially 
established  and  occasionally  updated  by  a  human 
being,  a  computer,  or  some  other  external 

intelligence  (Weinstein,  1980:  38). 

4.  'Holistic'  means  of  or  relating  to  the  theory 

that  a  being  [or  thing]  has  an  identity  other  than 
and  exceeding  the  total  or  sum  of  its  parts 

(Grolier,  1976:  458).  [This  is  more  than  just  mere 
synergistic  cooperation.]  In  the  context  of  this 
thesis,  'total  systems  concept'  will  be  used 
interchangeably  with  'holistic'. 

Although  both  robot  and  android  tend  to  suggest  humanoid 

shapes,  notice  the  definitions,  given  above,  do  NOT  say  that 

either  one  is  or  must  be  humanoid  in  appearance.  These 

definitions  show  the  conceptual  difference  among  the 

different  types  or  classes  of  the  mechanisms  defined.  These 

mechanisms  are  all  frequently  and  casually  termed  'robot'! 

Since  Dr.  Kaleps  specified  a  robot  functioning  without 

direct  human  intervention  and  supervision,  the  definition 

best  fitting  that  description  was  an  android.  Thus  the  term 

'android',  rather  than  'robot',  is  used  in  conjunction  with 
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Dr.  Kaleps'  goal.  As  a  result,  the  R&D  program  defined  by 
this  thesis  (if  carried  through)  should  produce  an  android 
able  to  repair  and  refuel  an  aircraft  in  a  hazardous 
environment. 

It  must  be  noted  at  this  time,  the  term  android  is  not  an 
agreed  upon  term  in  the  scientific  community.  Of  those 
terms  defined  in  this  thesis,  the  only  commonly  agreed  upon 
term  is  the  definition  of  an  industrial  robot.  Mr.  Lohr  in 
his  discussion  about  the  history  of  this  definition  made  it 
quite  clear  that  it  took  considerable  time  and  effort  to  get 
agreement  on  this  one  definition  (Seminar,  1982; 
Electronics,  1982:  39).  However,  the  sophisticated 
mechanism  desired  by  Dr.  Kaleps'  requirement  is  not  an 
industrial  robot  and  should  not  be  confused  with  one.  Thus, 
the  term  android  is  used  to  denote  this  difference.  One 
could  say  that  'robot'  was  the  generic  term  while  'android' 
was  a  specific  subclass. 

Objectives.  Specifically,  the  objectives  addressed  by 
this  thesis  were: 

1.  Determine  the  user  requirements  for  aircraft 
maintenance. 

2.  Define  the  research  and  development  requirements  for 
a  program  to  achieve  the  android  described  by  Dr.  Kaleps. 
More  specifically,  this  program  is  to  be  used  by  AFAMRL  and 
other  USAF  agencies  to  develop  and  realize  a  detailed  R&D 
plan.  This  thesis  sets  guidelines  for  the  proposed  research 
and  development. 


3.  Construct  a  mobile  platform  for  future  use  and 
development  by  APIT  students  and  faculty  for  testing  various 
concepts  of  the  R&D  program.  By  definition,  this  platform 
by  itself  is  not  a  robot,  but  is  a  mobile  base  on  which  the 
features  of  a  robot,  and  then  an  android,  may  be  designed, 
built,  and  tested.  More  specifically,  the  mobile  platform 
associated  with  this  thesis's  hardware  project  will:  a)  be 
self-contained,  that  is,  it  will  have  its  own  'on  board' 
power  system;  and  b)  the  platform  and  motors  will  support 
about  100  pounds.  (This  weight  includes  the  platform's 
structure,  wheels,  motors,  power  supply,  and  other 
equipment. ) 

4.  Based  on  1.  and  2.,  recommend  futher  AFIT  efforts. 

The  R&D  program  establishes  a  general  program 

identifying  functional  areas  requiring  further  research  and 
development.  This  thesis  also  shows  where  primary 
governmental  support  is  needed:  the  general  areas  of  R&D  in 
which  AFIT,  AFAMRL ,  and  other  agencies  could  participate. 
This  participation  could  be  through  support  of  industrial 
and  academic  research  as  well  as  conducting  their  own 
in-house  research.  Further  support  and  participation  should 
be  through  conference  sponsorship  and  by  enhancing 
communication  among  the  different  robotic/android 
disciplines . 

Once  a  detailed  R&D  plan  is  established,  a  seven  year 
time  frame  is  suggested  as  sufficient  time  for  the  results 
of  the  plan  to  be  realized.  This  time  period  was  arrived  at 


based  on  discussions  with  Lt  Mayer  of  the  Materials 
Laboratory  (Mayer,  1981).  Also,  examination  of  the 
literature  made  this  period  appear  to  be  a  reasonable  length 
of  time,  since  reports  of  an  existing  generalized  household 
robot  prototype  were  found.  The  reports  expected  this 
prototype  to  be  field  tested  in  1985  (Asimov,  1982b:  10, 
13). 

The  hardware  project  provided  a  moveable  platform  and  a 
means  for  using  microcomputer  generated  signals  to  control 
the  platform  motors.  This  platform  could  provide  the  basis 
for  future  AFIT  projects  and  theses  addressing  the  control, 
manipulator,  intelligence,  and  other  android/robotic 
functions.  In  past  robotics  efforts  conducted  by  AFIT, 
great  interest  was  expessed  in  the  artificial  intelligence 
areas,  such  as  motion  algorithms,  pattern  recognition  (both 
verbal  and  visual),  as  well  as  sensor  controls  and 
simulations.  No  interest  could  be  generated  in  the  motors 
and  motor  controllers.  This  work  was  important  because 
without  movement,  the  platform  could  not  be  used  to  test  and 
evaluate  possible  android  functions  as  they  were  developed. 
Thus,  initially,  the  platform  must  be  made  to  move,  even 
without  intelligence.  The  hardware  project  associated  with 
this  thesis  accomplished  this,  and  provided  the  necessary 
access  to  the  motors  for  computer  control  (for  expandable 
intelligence ) . 

Due  to  resource  restrictions  at  this  time,  the  majority 
of  the  effort  was  expended  in  defining  goals,  and  getting 


individuals  interested  in  working  on  these  concepts,  ideas, 
and  proposed  improvements.  This  included  capturing  the 
interest  of  the  students  and  faculty  of  AFIT,  as  well  as  the 
interest  of  researchers  in  other  USAF  agencies.  Another 
great  need  at  this  time  was  the  organization  of  the 
materials  on  hand  from  previous  AFIT  efforts.  This 
organization  was  needed  because  much  of  the  documentation  on 
previous  efforts  had  been  lost  or  was  incomplete.  Further¬ 
more,  the  hardware  project  was  made  as  modular  as  possible, 
providing  minimal  upgrade  effort  as  improved  resources 
became  available. 

Assumptions 

This  thesis  was  based  on  these  assumptions: 

1.  Future  AFIT  students  and  faculty  would  continue  the 
research  suggested  by  this  thesis. 

2.  Those  research  areas  and  projects  requiring  more 
manhours  and  resources  than  AFIT  students  and  faculty  can 
provide  would  be  supported  and/or  accomplished  by  AFAMRL, 
the  Air  Force,  and  other  government  agencies. 

3.  Funds  and/or  manpower  would  be  provided  to 

accomplish  the  necessary  research  and  development. 

4.  Industry  would  continue  its  research  in  this  field 
and  advance  the  state  of  the  art  in  its  own  areas  of 


interest. 


The  methods  which  achieved  these  objectives  were: 

The  R&D  Program.  The  R&D  program  was  developed  by 
reviewing  the  literature,  and  contacting  other  scientists 
and  roboticists.  This  contact  consisted  of  interviews, 
letters,  and  phone  calls.  The  areas  for  future  research 
were  established  through  projections  based  on  the  current 
knowledge  in  the  given  area.  The  user  requirements  were 
defined  through  interviews  with  USAF  officers  and  enlisted 
personnel  including  both  maintenance  and  flying  personnel. 
These  requirements  were  further  defined  by  observation  of  a 
flight-maintenance  crew  during  typical  pre-  and  post-flight 
operations. 

The  Platform.  The  platform  project  was  accomplished  by 
reviewing  and  evaluating  previous  AFIT  efforts.  The 
platform  design  was  based  on  these  experiences  and 
incorporating  newly  available  concepts.  Some  of  these 
designs,  decisions,  and  concepts  were  implemented,  tested, 
evaluated,  and  redesigned  (as  necessary).  The  limit  here 
rested  with  resource  availability.  Suggestions  for  future 
efforts  to  improve  and  expand  the  capabilities  of  this  basic 
platform  were  made. 

Organization 

This  chapter  briefly  introduces  the  reader  to  robotics 
and  its  terms  through  a  brief  history,  and  by  defining  the 
main  terms  of  interest:  industrial  robot,  robot. 


and 


android.  These  definitions  and  history  leads  into  a  summary 
of  the  objectives  of  this  thesis  and  the  assumptions 
necessary  to  accomplish  those  objectives.  Finally,  the 
approach  used  to  accomplish  the  thesis  objectives  is  briefly 
described. 

Chapter  Two  describes  the  user  requirements  in  more 
detail.  These  requirements  resulted  from  structured 
analysis  diagrams  and  a  literature  review.  Chapter  Three 
discusses  the  desired  state  of  the  art  and  the  current  state 
of  the  art  as  related  to  the  user  requirements  presented  in 
Chapter  Two.  Chapter  Four  presents  the  proposed  research 
and  development  program.  Chapter  Five  presents  the  results 
jf  the  mobile  platform  project.  Chapter  Six  presents  a 
short  discussion,  and  the  recommendations  and  conclusions. 
An  annotated  supplemental  bibliography  is  provided  in 
addition  to  the  standard  reference  bibliography.  The 
analysis  diagrams,  for  Chapter  Two,  are  provided  in  Appendix 
A  with  the  data  definitions  in  Appendix  B.  The  8080-based 
assembly  language  code  generated  by  the  mobile  platform 
project,  described  in  Chapter  Five,  is  given  in  Appendix  C. 
Appendix  D  is  a  list  of  contacts  and  suggested  contacts 
which,  with  the  annotated  supplemental  bibliography, 
provides  a  list  of  additional  reference  material  for  those 
interested  in  the  follow  on  work  for  this  thesis.  Appendix 
E  gives  the  specifications  for  the  motors  used  in  the  mobile 
platform  project. 


These  user  requirements  were  the  analytical  results  of 
direct  observations,  interviews,  and  discussions  with  4950th 
Test  Wing  Organizational  Maintenance  Squadron  (4950th 
TW/OMS)  and  AFIT  students  who  were  Navigators,  Radar 
Navigators,  Pilots,  Chiefs  of  Maintenance,  Flight  Engineers, 
Maintenance  Personnel,  and  so  on.  (The  names  of  the 
individual  interviewees  are  given  in  the  bibliography. )  The 
two  planes  directly  observed  were  a  T-39B,  and  a  T-37  from 
the  4950th  TW.  The  discussions  and  comments  covered 
aircraft  such  as  B-52s,  F-4s,  C-141s,  KC-135s,  and  others. 
Those  comments  and  suggestions  which  do  not  bear  directly  on 
this  thesis  topic,  but  are  considered  to  have  merit,  for 
consideration  have  been  included  in  the  recommendations 
section.  Again,  the  issue  at  hand  is  the  definition  of 
android  research  initiatives  resulting  in:  "an  android 
capable  of  repairing  and  refueling  aircraft  in  a  hostile 
environment  without  direct  human  intervention  or 
supervision"  (Kaleps,  1981). 

Two  primary  scenarios  of  interest  to  the  OSAF  were  a 
wartime  environment  and  a  peacetime  environment.  The  major 
differences  between  the  two  were  the  existence  of  hazardous 
atmospheric  conditions,  the  requirements  for  rapid 
turn-around  times  for  combatant  aircraft,  and  a  decision  of 
which  risks  were  acceptable  or  not.  Hazardous  atmospheric 


conditions  would  be  primarily  due  to  chemical/biological 
warfare  tactics  and  the  use  of  small,  tactical  nuclear 
weapons.  For  whichever  aircraft  were  involved  in  warfare 
(regardless  of  whether  they  were  tankers,  fighters,  bombers, 
or  other  aircraft),  minimal  ground/down  time  is  desired. 
During  wartime,  some  risks  would  be  acceptable  which  would 
not  be  during  peacetime. 

The  wartime  situation  would  consist  of  doing  whatever 
had  to  be  done  to  keep  the  planes  flying.  The  user 
requirements  addressed  that  situation  directly.  Those 
additional  duties  which  could  be  done  during  peacetime  will 
be  addressed  as  recommendations.  Basically,  the  following 
duties  are  accomplished  for  all  aircraft  either  during 
post-flight,  pre-flight,  and/or  ground  maintenance: 

1.  physically  inspect  the  aircraft. 

2.  Hook/unhook  mobile  power  plants  to  the  aircraft. 

3.  Refuel  the  aircraft. 

4.  Initiate  safety  procedures  for  the  aircraft. 

5.  Repair  the  aircraft. 

6.  Replenish  armaments  onboard  the  aircraft. 

7.  Decontaminate  the  aircraft. 

8.  Follow-me/Park-on-me/Marshall  guidance  for  the 

aircraft. 

9.  Secure  the  aircraft. 

All  of  the  above  are  done  on  an  as  needed,  per  aircraft 
basis. 
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Figure  1.  A-0,  Maintain  aircraft 


To  define  and  describe  the  activities  of  the  aircraft 
maintenance  people,  analysis  diagrams  similar  to  SADT 
diagrams  were  constructed.  SADT  stands  for  Structured 
Analysis  Design  Technique  (Ross,  1977:  13).  The  information 
base  for  these  diagrams  was  derived  from  the  various 
interviews  of  flight  and  maintenance  personnel.  Figures  1 
and  2  show  the  overall  and  general  concepts  dealt  with;  the 
remaining  diagrams  were  placed  in  Appendix  A.  The  data 
dictionary  associated  with  these  diagrams  was  placed  in 
Appendix  B  (Peters,  1981:  76). 


15 


Examining  these  diagrams,  several  common  themes  were 
noticeable.  These  were  identification,  reports  and 
histories,  and  status.  Identification  included  identify 
aircraft,  identify  location,  identify  component  and  so  on. 
People  usually  accomplished  these  identifications  visually. 
The  histories  were  written  data  compilations.  The  written 
reports  were  required  by  Air  Force  Maintenance  Regulations. 
The  status  was  an  immediate  data  evaluation  of  a  given 
activity  and  frequently  changing.  A  status  could  be  written 
or  verbal. 

Among  the  activities  performed  by  maintenance  people 
were:  seeing  (vision),  walking,  climbing,  carrying, 
grasping,  hearing,  driving,  pushing,  pulling,  inserting, 
clamping,  twisting,  lifting,  and  precision  inserting  or 
matching.  The  implied  activities  were  such  things  as 
memory,  a  knowledge  of  duties  and  how  to  accomplish  them, 
and  a  knowledge  of  required  materials  and  how  to  get  them 
(be  it  a  replacement  from  bench  stock,  armaments  from 
munitions,  or  special  ordering  an  item  from  supply).  These 
were  the  duties  which  people  did  while  maintaining  aircraft. 

Visual  activities  included  locating  and  checking  the 
aircraft  components.  Aircraft  components  included  flight 
controls,  hydraulics,  landing  gear,  engines,  black  boxes, 
and  air  frames.  Checking  component  tolerances  involved 
reading  TO  specifications  and  comparing  those  values  with 
the  current  component  values  as  indicated,  visibly,  by 
meters  and  other  devices.  Diagnosing  bad  components  and 


their  repair  or  replacement  were  also  usually  performed 
visually.  Checking  the  surroundings  (for  both  safety  and 
security  reasons)  included  looking  for  and  remov. 
unauthorized  personnel,  foreign  objects,  and  any  equipment 
out  of  place.  Directing  aircraft  involved  visually  locating 
and  leading  the  aircraft  to  the  desired  location.  Locating 
objects  and  physical  locations  were  also  normally  visual 
activities.  Again,  these  were  people  oriented  activities. 

But  what  could  an  android  do,  and  how?  The  duties  won't 
change.  The  same  activities  are  required  to  keep  an 
aircraft  flying  whether  a  person  or  an  android  does  the 
maintaining.  However,  the  mechanism  needed  to  accomplish  a 
task  may  not  be  the  same  for  both.  For  example,  a  person 
would  identify  an  aircraft's  type  by  using  vision  (most 
often);  an  android  could  use  vision,  an  identity  sijnal,  *tz 
a  combination  of  both.  An  identity  signal  could  be  used  to 
identify  people,  places,  objects,  locations,  or  even 
aircraft  components.  To  facilitate  android  maintenance, 
some  additional  modifications  to  the  aircraft  and  its 
components,  as  well  as  to  flight  line  facilities  will 
probably  need  to  be  done. 

Since  the  android  was  expected  to  work  during  hazardous 
conditions,  it  was  not  expected  to  enter  any  area  occupied 
by  people  unless  those  people  were  wearing  proper  protective 
gear.  An  android  working  in  a  hazardous  environment  must  be 
assumed  to  be  contaminated.  If  an  android  entered  the 
aircraft,  from  the  hazardous  environment,  it  then  could 


contaminate  the  area  it  entered.  This  did  not  preclude 
rearming  since  rearming  could  be  done  from  the  exterior  or 
through  hatches  away  from  the  crew  areas.  For  example, 
bombs,  on  planes  that  carry  them  internally,  are  loaded 
through  open  bomb  bay  doors.  This  eliminated  the  need  for 
this  research  and  development  program  to  address  the 
climbing  function. 

Since  aircraft  must  have  relatively  smooth  areas  for 
taxi-ways,  take  offs,  and  landings,  the  android  could  move 
by  using  wheels  or  tank  type  tracks.  However,  a  hole  with  a 
radius  approximately  1/2  the  aircraft's  wheel  radius,  and 
approximately  1/4  radius  deep  will  cause  the  aircraft 
difficulty — if  the  aircraft  were  unable  to  avoid  the  hole. 
If  the  android  had  wheels,  it  could  experience  similar 
difficulties.  A  tracked  vehicle  could  minimize  those 
difficulties,  enabling  the  android  to  go  places  where  the 
aircraft  would  not.  During  war,  it  is  not  unreasonable  to 
expect  holes  in  taxi-ways  and  aprons. 

Tracks  on  the  android  would  also  enable  the  android  to 
cross  hangar  door  tracks,  door  jams,  and  other  similar  low 
(height)  obstacles  more  easily.  Bench  stock  is  usually 
located  within  the  appropriate  hangar  or  hangar  area, 
usually  on  ground  level  or  else  up  one  or  two  steps.  A  few 
steps  could  be  replaced  by  a  ramp  which  could  be  easily 
navigated  by  the  android.  Bench  stock,  if  located  upstairs, 
would  have  to  be  accessed  through  an  elevator  or  ramp  to 
facilitate  movement  of  heavy  equipment  or  components  by 
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maintenance  people  (or  an  android). 


The  android  would  need  a  carrying  capability  which 
includes  the  ability  to  grasp  or  hold  items  such  as  test 
equipment,  fuel  hoses,  and/or  aircraft  components. 
Frequently  used  tools  such  as  certain  screwdrivers  and 
wrenches  could  be  part  of  the  android  manipulator  and 
alternate  with  a  grasping  end  effector.  An  android  could 
have  one  or  more  arms  and  end  effectors.  There  should  be  no 
need  to  duplicate  human  functional  appearance  unless 
psychology  demanded  it.  However,  this  thesis  did  not  deal 
with  the  psychological  aspects. 

Basic  Maintenance  Tasks  Summary 

Each  analysis  diagram  in  Appendix  A  is  accompanied  by 
descriptive  text.  The  following  summarizes  the  commonly 
required  tasks  for  aircraft  maintenance. 

1.  Identify  aircraft  mission. 

2.  Form  aircraft-ID, 

2a.  from:  Aircraft  type  identif icaton,  and 
2b.  from:  Specific  aircraft  identification. 

3.  Lead  and  direct  aircraft 

4.  Make  pre-  and  post-arrival  security  check. 

5.  Perform  ground  safety  check. 

6.  Decontaminate  aircraft. 

7.  Inspect  aircraft  (post-flight  check  requirement);  the 
same  as  #19. 

8.  Implement  aircraft  component  check  list. 


9.  Follow  up  crew  debriefing  comments. 

10.  Physically  locate  next  component  on  list. 

11.  Check  component  tolerances. 

12.  Replenish  consumables. 

13.  Diagnose  bad  component  problem. 

14.  Repair  or  replace  bad  component. 

15.  Determine  rearm/refuel  sequence. 

16.  Rearm  aircraft. 

17.  Refuel  aircraft. 

18.  Apply  external  power  to  aircraft. 

19.  Inspect  aircraft  (pre-flight  check  requirement);  the 
same  as  #7. 

20.  Perform  air  safety  check. 

21.  Generate  data: 

21a.  Statuses  (aircraft  statuses  and  component 
conditions ) 

21b.  Reports 
21c.  Histories 

21d.  Identifiers  (aircraft  ID  and  component  ID) 

21e.  Diagnoses. 

22.  Other  items  used: 

22a.  TOs 

22b.  Checklists 
22c.  Data  generated 

22d.  Tools  and  equipment  as  required 
22e.  Various  "controls". 

This  list  of  tasks  was  derived  from  the  lowest  level  of  the 


analysis  diagram  boxes.  The  android  capabilities  needed  to 
meet  these  tasks  is  discussed  in  Chapter  Three  as  the 
"desired  state  of  the  art". 
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III.  Android  Requirements 


Desired  Capabilities 

The  android  capabilities  needed  to  accomplish  those 
tasks  defined  in  Chapter  II  are  discussed  here.  It  is 
important  to  recall  that  mimicking  human  actions  is  not 
necessarily  the  best  way  to  accomplish  a  task.  However,  if 
a  better  methodology  is  not  available,  and  the  task  must  be 
accomplished,  then  mimicry  is  an  acceptable  interim 
solution. 

It  is  extremely  important  to  realize  that  the 
human  system  performs  its  function  because  of 
unsurpassed  hand-eye  coordination.  Nonetheless,  the 
human  system  is  probably  a  very  poor  model  for 
performing  precision  operations  under  load.... Note 
that  no  human  hand  is  capable  of  precision 
measurement  or  is  capable  of  precision  machining 
operations  under  load.  Because  this  is  true,  the 
human  model  for  robotic  manipulators  is  adequate  for 
simple  repetive  tasks  such  as:  Pick-and-Place,  Spot 
Welding,  Spray  Painting,  Surveillance,  Unloaded 
Assembly,  etc.  (Tesar,  1982:  14). 

The  android  needs  perception,  mobility,  manipulators, 
and  IC2  (intelligence,  control,  and  communication)  as 
general  capabilities.  Perception  covers  the  sensory 
aspects.  Mobility  covers  the  android's  own  movements,  while 
the  manipulators  deal  with  the  android  moving  objects  other 
than  itself.  For  the  purpose  of  this  thesis,  IC2  is  defined 
as  the  intelligence,  control  and  communication  function(s) 
combined.  These  three  are  grouped  together  because  of  their 
strong  interweaving  and  interaction.  IC2  includes  the 


feedback  control  loops  required  for  manipulation  and 
perception,  the  communication  between  the  android's  own 
systems,  the  communication  with  the  world,  and  the 
individual  computer  control  aspects.  Additionally, 
communication  and  sensing  tend  to  overlap  when  one  considers 
robotic  sensing  as  being  divided  into  two  parts.  These  two 
parts  could  be  classed  as 

1)  internal  robotic  sensing,  which  monitors  the 
state  of  the  robot's  system,  and  2)  external  robotic 
sensing,  which  monitors  the  state  of  the  robot's 
environment  (Nitzan,  1980:  182). 

Internal  robotic  sensing  will  be  considered  part  of  IC2, 

while  external  sensing  will  be  considered  as  the  previously 

mentioned  perception.  In  order  to  accomplish  those  tasks 

currently  done  by  aircraft  maintenance  personnel,  the 

android  must  be  able  to  sense  both  its  internal  state  and 

its  environment's  state.  Not  only  must  it  sense  these  two 

states,  but  it  must  be  able  to  coordinate  the  two  data  sets 

and  then  arrive  at  the  proper  actions.  It  must  be 

remembered  that  not  all  of  the  sensors  need  to  be  physically 

present  on  the  android,  as  long  as  it  has  some  method  of 

receiving  the  necessary  remote  sensor  data  (Nitzan,  1980: 

191). 

IC2  also  includes  the  hardware  and  software  which  allows 
judgement,  decision  making,  and  the  interfacing  of  the 
android's  systems  to  itself  and  to  the  world.  These  areas 
overlap  and  interact  with  each  other  in  providing  the 
desired  results. 

Some  of  the  tasks  developed  in  Chapter  II  require  that 
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the  android  locate,  identify,  inspect,  and  move.  These  four 
activities  involve  varying  amounts  of  perception.  Primary 
candidates  for  these  perception  requirements  are  primitive 
sight  mechanisms  (PSM),  and  primitive  hearing  mechanisms 
(PHM ) .  These  two  perceptions  account  for  most  of  the 
sensory  information  required  to  carry  out  aircraft 
maintenance.  If  a  need  for  'taste'  or  'smell*  is  required 
at  a  later  date,  then  these  areas  could  be  developed  at  that 
time.  They  will  not  be  considered  here.  Touch  is  discussed 
in  the  discussion  involved  with  manipulators  and  control, 
where  it  is  employed  more  often,  rather  than  here. 

The  primitive  hearing  mechanisms  use  acoustic 
transmitters  and  receivers.  Military  aircraft  already 
possess  a  transponder  system  which  provides  a  radio 
' identif ication-friend-or-foe'  (IFF)  signal.  This  is  a 
query  system,  where  the  identification  signal  is  only  sent 
in  response  to  a  request  for  aircraft  "verification".  A 
similar,  acoustic  version  of  this  could  be  used  on  major 
aircraft  components,  ground  equipment,  buildings,  personnel 
identification  tags,  and  other  obstacles. 

This  IFF  signal  would  be  backed  up  by  a  visible 
identification  code  (VIC)  which  would  employ  a  primitive 
sight  mechanism.  (Since  the  Air  Force  has  stock  numbers  for 
virtually  everything  it  uses,  what  to  use  as  the 
identification  code,  initially,  is  not  dealt  with  here. ] 
This  code  is  similar  in  concept  to  those  codes  which  various 
stores  and  the  railroad  use.  The  android  either  knows  where 


to  look  for  the  VIC  or  else  a  marker,  such  as  an  LED,  would 
denote  where  the  VIC  was.  The  VIC  would  be  a  permanent  part 
of  each  component  and  each  aircraft.  Each  aircraft  would 
have  VICs  at  various  points  on  the  aircraft  to  allow  the 
android  to  know  where  it  was  with  respect  to  the  aircraft 
and  the  aircraft  components.  These  latter  VICs  would 
facilitate  finding  various  components  and  recepticles  on  the 
aircraft.  Each  aircraft  would  have  a  VIC  which  designates 
the  aircraft  type  and  which  particular  aircraft  it  was. 
Just  as  the  VICs  would  be  used  on  aircraft  to  back  up  the 
IFF,  they  would  be  used  on  ground  equipment,  buildings, 
personnel  identification  tags,  and  other  obstacles. 
Together,  the  PSM  and  PHM  provide  reliable  identification. 

Motion  perception  deals  primarily  with  collision 
avoidance.  An  android  avoids  collisions  by  gathering  and 
manipulating  data,  and  then  making  decisions  based  on  that 
data.  Acoustic  sensors  would  warn  the  android  of  objects, 
their  distance,  and  relative  motion  and  speed. 
Additionally,  primitive  1-D  or  2-D  vision  would  be  coupled 
with  the  acoustic  sensors.  By  coupling  it  with  the  acoustic 
sensors,  vision  need  not  be  the  sole  means  of 
identification.  The  vision  system  would  show  the  android 
where  a  potential  object  or  obstacle  is,  then  the  android 
would  direct  its  acoustic  sensors  toward  the  object  to 
determine  whether  or  not  it  was  really  there,  its  distance, 
and  its  relative  speed.  The  sonar  sensors,  presently 
available,  are  of  two  general  types:  1)  pin  point,  and  2) 
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broad  beam.  Not  only  would  the  basic  sonar  sensors  be  used, 
but  the  IFF  subsystem  would  be  used  simultaneously  to 
provide  additional  information  and  confirmation  as  well. 
These  data  sets  would  become  the  database  for  decision 
making.  Thus  no  one  single  sense  is  used  to  identify  items 
or  objects.  If  an  object  could  be  certainly  identified  by 
just  one  sense,  using  a  judgement  algorithm  would  speed  up 
the  identification  procedure,  and  thus  the  decisions 
necessary  to  avoid  collisions,  or  to  locate  components  and 
other  objects. 

Permanently  stationary  objects  could  transmit  their 
location  and  identification  either  upon  query  or 
continuously.  The  continuous  identification  versus  query 
initiated  identification  would  depend  upon  the  hazard  which 
the  obstacle  or  object  presented  as  well  as  the  desired 
level  of  security.  A  transmitted  location  implies  either  a 
reference  map  within  the  android  or  that  the  android  has 
access  to  a  reference  map,  so  that  the  location  information 
is  meaningful. 

Inspection  of  an  aircraft,  its  components,  or  the  flight 
line  requires  evaluation  as  well  as  perception.  The  android 
can  identify  and  find  various  components  and  objects  through 
primitive  sight  mechanisms  and  primitive  hearing  mechanisms, 
but  inspection  also  requires  determining  whether  or  not  the 
component  or  object  of  interest  is  acceptable  or  allowable. 
This  determination  is  based  on  test  results,  and  their 
comparison  to  the  TO  specifications.  Judgement  will  be 


addressed  with  intelligence  and  in  the  recommendations,  not 
here.  Specially  designed  test  equipment,  developed  for  ar* 
android,  will  be  needed  as  well  as  the  modification  of 
existing  test  equipment  to  allow  direct  access  to  the  test 
equipment  for  the  android's  data  gathering.  Further 
modifications,  other  than  to  the  test  equipment,  may  be 
required  to  facilitate  android  maintenance. 

One  such  potential  modification  would  allow  the  android 
direct?  access  to  the  on  board  aircraft  computer  systems. 
Many  aircraft  components  have  built  in  computer  systems  and 
computer  diagnostics.  With  a  lead  or  plug  directly  attached 
to  the  android,  these  would  be  used  by  the  android  for  data 
gathering  and  testing.  If  these  self-diagnostics  were  on 
all  major  aircraft  components,  then  the  need  for  separate, 
android  specialized  test  equipment  would  be  minimized. 

By  judiciously  modifying  existing  aircraft  components, 
the  android  could  use  manipulators  with  primitive  end 
effectors.  Two  feasible  modifications  require  1)  an 
aircraft  component  modification  which  allows  easier  access 
by  a  non-human  hand,  and  2)  the  relocation  of  aircraft 
components  [if  necessary]  to  facilitate  access  by  an 
android.  The  android  need  not  grasp  a  wrench  or  other  tool 
exactly  in  the  way  a  person  would.  The  android  would  have 
several  manipulators,  each  with  a  set  of  rotating, 
interchangeable,  self-locking  end  effectors.  [Remember,  the 
android  is  not  limited  to  two  arms.]  Each  end  effector 
would  be  a  different  tool.  At  least  two  manipulators  would 


have  several  matched  tools  to  facilitate  moving  or  removing 
larger  components  and  items.  Screwdrivers,  wrenches,  test 
leads  or  plugs,  and  other  commonly  used  tools  would  be  part 
of  the  end  effector.  To  handle  the  grasping  of  aircraft 
components  or  other  items,  a  threaded  receptacle  in  the 
component  with  a  matching  threaded  extrusion  as  an  end 
effector  could  replace  the  need  for  an  end  effector  with  the 
ability  to  use  human  door  handles  or  human  component 
* pullers ' . 

Allowing  the  android  to  have  several  manipulators 
facilitates  the  use  of  different  classes  of  manipulators. 
These  various  classes  of  manipulators  and  their  related  end 
effectors  are  based  on  the  requirements  which  they  fullfill, 
such  as  low  torque,  precise  force  measurements,  precision 
matching  or  inserting,  high  torque,  and  amount  of  mass  it  is 
able  to  manipulate.  Those  manipulators  requiring  precise 
force  measurements  would  have  end  effectors  capable  of  such 
precision.  Those  manipulators  able  to  do  precise  matching 
and  insertion  would  have  end  effectors  to  make  computer 
outlet  connections,  test  equipment  lead  connections,  and 
such.  There  could  be  combinations  of  these,  and  others  to 
meet  the  needs  of  aircraft  maintenance  by  an  android.  This 
does  require  a  sense  of  touch,  however.  The  sense  of  touch, 
or  a  recognition  of  the  amount  of  force  applied,  is  really 
more  of  a  control  function. 

Previously,  the  perception  aspects  of  mobility  were 
emphasized.  The  scenario  under  di:-  ussion  is  a  hazardous 
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environment  due  to  warfare.  One  consequence  of  war  is 
damage  to  the  ground  from  various  weapons.  In  the  textual 
portion  of  Appendix  A,  it  is  noted  that  some  holes  in  the 
ground  would  not  interfere  with  an  aircraft  on  takeoff, 
landing,  or  taxying.  This  was  because  either  the  larger 
holes  are  avoidable  or  else  the  holes  are  small  enough  that 
the  aircraft  wheels  can  safely  cross  them. 

Because  of  the  possible  ground  damage,  wheels  are  not 
necessarily  the  best  means  of  movement  for  the  android. 
[Although  there  are  tired  vehicles  which  can  navigate  marshy 
country,  the  primary  candidate  for  mobility,  as  addressed 
here,  is  the  tracked  vehicle. 3  Tank-type  tracks  provide  a 
more  effective  method  of  movement.  Even  in  a  non-war 
environment,  the  tracks  are  more  effective  on  the  flight 
line  because  of  the  inclement  weather,  crossing  doorsills  or 
hangar  door  tracks,  and  similar  obstacles.  The  tracks 
minimize  the  need  for  circumventing  holes  and  other 
obstacles  in  the  terrain.  The  tracks  also  provide  a  more 
stable  base  from  which  the  android  may  work. 

The  final,  general  android  capability  to  be  discussed 
here  is  'IC2'.  Intelligence,  communication,  and  control  [in 
conjunction  with  mobility]  are  what  make  the  android  an 
android  and  not  simply  a  robot.  Control  combines  with 
intelligence  and  enables  the  android  to  do  what  it  'should 
do'  at  each  level.  These  levels  include  the  overall, 
'gross'  concept  of  aircraft  maintenance;  the  level  which 
deals  with  how  much  torque  or  pressure  is  required  to  screw 
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down  a  particular  screw  or  where  and  how  to  insert  a  plug  to 
carry  out  a  diagnostic  procedure;  and  even  lower  to  the 
level  which  deals  with  each  sensor  or  microcomputer  and 
their  priority  to  interrupt  during  an  in-progress  function 
or  routine. 

One  aspect  of  control,  without  a  direct  linkage  to 
intelligence,  is  the  feedback  control  loop.  [It  must  be 
noted  however,  that  closed  loop  feedback  is,  in  one  sense, 
limited  intelligence.]  In  digital  control,  computer 
hardware  and  software  are  combined,  with  and  without 
mechanistic  control  techniques,  to  provide  the  controlling 
functions  and  factors.  One  extension  of  this  is  the  use  of 
pattern  recognition  as  the  sensory  input  factor  for  the 
feedback  control  loops.  The  more  advanced  the  feedback 
control  technique  is,  in  general,  the  more  complex  the 
computer  requirements.  It  is  closed,  feedback  control  loops 
which  will  help  give  the  android  its  sense  of  touch  and  its 
ability  to  have  precise  perception.  This  aspect  of  control 
uses  internal  communication  and  interfaces. 

Another  communication  aspect  might  be  the  networking  of 
the  various  modules  (with  or  without  digital  or  analog 
processors)  connected  to  and  located  within  the  android.  It 
is  also  the  exchange  of  information  between  the  android  and 
another  android  or  robot,  or  a  person,  or  its  required 
reporting  'official'  (the  computerized  maintenance  system  or 
the  chief  of  maintenance,  for  example),  or  even  aircraft 
components.  One  form  or  another  of  communication  results  in 


all  the  gathered,  stored,  and  generated  data. 

Most  people  prefer  use  speech,  rather  than  having  to 
punch  buttons,  pull  levers,  punch  and  insert  computer  cards, 
or  type  out  instructions.  Thus  the  android  must  be  able  to 
speak  to  people  and  understand  what  the  people  are  saying. 
Part  of  speaking  to  people,  is  having  the  android  respond  in 
some  manner  to  whomever  spoke  to  it,  such  as  a  special 
blinking  light  or  a  verbal  response.  People  who  are  not 
used  to  machines,  especially  quasi-intelligent  machines, 
need  to  know  their  command  was  heard.  Especially  if  there 
is  a  time  lag  between  hearing  the  command  and  an  active 
response  by  the  android.  This  time  lag  would  be  the 
android's  "thinking"  or  deciding  time.  [Do  remember  that 
people  take  thinking  time,  also. ]  This  is  a  form  of 
communication.  Understanding  speech  is  a  function  of 
pattern  recognition,  while  speaking  is  a  result  of  either 
preprogrammed  responses  or  artificial  intelligence. 

Several  of  suggested  methods  (primary  candidates),  both 
directly  and  indirectly,  require  a  large  data  storage 
capability.  If  these  methods  are  used,  then  this  implies 
the  android  might  need  to  supply  this  capability.  To  some 
extent,  this  is  true.  However,  if  the  computerized 
maintenance  system  (CMS)  continues  to  be  developed  and 
implemented,  then  a  working  'scratch'  memory  area  combined 
with  the  android's  direct  access  to  the  CMS  would  minimize 
how  much  data  must  be  stored  at  all  times  within  the 
android.  For  example,  once  the  aircraft  is  identified,  the 


android  communicates  with  the  CMS,  and  loads  the  information 


and  directions  pertinent  to  that  particular  aircraft 
including  the  report  and  history  formats.  As  work 
progresses,  the  data  is  stored  in  these  formats  by  the 
android.  Thus,  when  a  job  or  report  is  completed,  or  the 
memory  constraints  require  it,  the  appropriate  data  is 
off-loaded  into  the  CMS.  Easy  access  to  the  CMS  aircraft 
diagrams  and  maps  provide  the  additional  data  necessary  for 
decision  making  without  having  to  maintain  a  large  database 
on  board  the  android  at  all  times. 

IC2  is  the  hardware,  firmware,  and  software  which 
enables  the  android  to  make  decisions,  exercise  judgement, 
to  communicate  with  itself  and  others,  and  to  control  itself 
and  what  it  does.  This  is  what  the  android  needs,  but  what 
is  currently  available? 


Current  State  of  the  Art 

The  functions  discussed  here  are  the  same  general 
capabilities  discussed  previously,  that  is,  IC2,  mobility, 
manipulators,  and  perception.  Vision  and  hearing  were  the 
two  major  areas  of  perception  discussed. 

Some  of  the  available  primitive  sight  mechanisms  can  be 
seen  daily  in  grocery  and  department  stores.  These  readers 
require  a  relatively  precise  orientation  of  the  reading  head 
over,  and  a  particular  distance  from,  the  code  to  be  read. 
Once  these  two  conditions  are  met,  the  code  is  read.  One 
and  two  dimensional  (1-D  and  2-D)  vision  capabilities  are 
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available  as  well.  The  National  Bureau  of  Standards  has 


been  working  in  the  control  area  of  robotics  for  some  time. 
One  area  of  control,  has  been  real  time  vision.  This  vision 
system  uses  a  camera,  strobe  type  of  light  source,  and  an 
8-bit  microprocessor.  It  is  limited  to  a  distance  of  one 
meter  and  has  a  36  degree  field  of  view  (VanderBrug,  1979: 
213-231). 


Of  course,  the  128  points  which  represent  the 
function  do  not  give  information  about  the  entire 
object.  They  only  contain  information  about  a 
particular  cross  section  of  the  object.  However,  in 
some  robot  vision  applications,  such  as  alignment 
and  feature  inspection,  this  may  be  sufficient.  In 
other  applications  where  it  is  not  sufficient,  the 
control  system  can  decide  that  additional  images 
from  other  perspectives  (such  as  closer  in,  higher, 
lower,  from  the  other  side)  are  required 
(VanderBrug,  1979:  216). 

Not  only  should  the  control  system  decide  if  additional 
images  from  the  camera  were  needed,  but  also  decide  if 
additional  information  from  the  other  sensors  available 
would  resolve  the  deficiency. 

One  possibility  is  the  combination  of  the  information 
from  both  a  1-D  and  a  2-D  vision  system.  The  Jet  Propulsion 
Laboratory  was  working  on  a  visual  tracking  system.  This 
system  assumes  the  tracker  has  acquired  the  object  and  must 
follow  it  around  a  scene.  This  particular  paper  deals  with 
feature  extraction  for  visual  tracking  and  the  principles 
involved  with  the  tracking  algorithm.  To  deduce  the 
internal  model's  errors,  an  inverse  Jacobean  matrix  is  used 
(Saund,  1979:  WP-2E ) . 

Most  vision  systems  are  very  limited  in  their  pattern 


recognition  abilities,  because  of  the  processing 
requirements.  But  as  previously  pointed  out,  that  would  not 
be  a  current  limitation  if  combined  with  data  from  other 
sensors,  and  with  the  current  progress  being  made  in 
microprocessor  capabilities.  Additionally,  a  backup  method, 
similar  to  that  used  with  the  Air  Force's  Communication 
Center's  OCR  Message  reader  and  sender  should  be  used  until 
vision  or  the  combination  of  vision  and  other  senses  is 
completely  reliable  and  available.  The  OCR  Message  Reader, 
when  it  is  not  sure  of  a  character  it  is  supposed  to  read 
and  then  send,  sounds  an  alarm.  The  operator  then  goes  to 
the  reader,  looks  at  the  character  on  display,  determines 
the  character,  and  then  tells  the  reader  what  character  it 
should  have  recognized.  Then  both  the  operator  and  the 
reader  return  to  their  normal  functioning  modes  (Tour, 
1982).  Thus,  the  android  would  transmit  its  video  to  the 
maintenance  shop,  and  sound  an  alarm  when  it  could  not 
decide.  Then  one  of  the  on-duty  maintenance  persons  could 
look  at  the  picture  in  question  and  tell  the  android  what  it 
needs  to  know.  However,  as  perception  systems  become  more 
reliable,  this  will  occur  less  often.  According  to  Joseph 
Engelberger , 

We  all  know  that  human  vision  serves  its 
possessors  in  a  spectrum  that  ranges  from  the 
near-blind  to  20/20  vision.  A  combination  of  20/20 
vision  and  20/20  ability  to  analyze  scenes  is  not  in 
the  cards  for  robots  in  this  century,  if  ever 
(Electronic,  1982:  55). 

The  overwhelming  shortfalls  in  the  area  of  vision  are  the 
equipment  required,  the  space  needed  to  house  the  equipment. 


and  the  limited  portability  of  the  equipment  while  in  use. 

The  available  primitive  hearing  mechanisms  are  acoustic 
sensors.  These  sensors  primarily  transmit  and/or  receive, 
such  as  the  military  aircraft  transponders.  To  use  these 
transponders  in  the  manner  described  previously,  they  need 
to  be  miniaturized  and  remain  functional.  Acoustic  sensors 
exist  now  with  pin  point  and  broad  beam  capabilities.  The 
phased  array  radar  technology  provides  pin  point  sensing 
capabilities  at  long  distances.  But  phased  array  radars 
tend  to  be  large,  fixed  units.  Thus  to  be  useful  for  an 
android,  the  phased  array  type  of  radar  would  have  to  be 
miniaturized  and  made  mobile. 

The  mobility  area  has  mixed  requirements  involving 
physical  implementations  and  control  considerations.  The 
tracked  vehicle  technology  ranges  from  moving  toy  tanks  to 
large  military  tanks.  The  track  movements  are  primarily 
mechanical.  The  need  here  is  for  appropriate  computer 
interfaces  which  allow  computer  control  of  the  tracks.  In 
fact 

vehicular  mobility  over  smooth  surfaces  can  be 
regarded  as  a  solved  problem.  Moreover ...  it  is 
evident  that  conventional  wheels  or  tracks  when 
coupled  with  appropriately  designed  passive 
suspension  systems  afford  effective  means  of 
transport  over  moderately  irregular  surfaces 
(McGhee,  1980:  167). 

According  to  McGhee,  most  of  the  work  done  for  vehicles  with 
wheels  or  tracks  was  done  for  the  Mars  Rover  project  which 
was  not  complete  at  the  time  the  above  paper  was  written. 

This  maintenance  android  is  not  expected  to  climb,  but 
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to  work  from  the  ground  (actually  the  flight  line  surface), 
a  ramp,  or  a  platform  when  available.  These  are  relatively 
smooth  surfaces  due  to  the  requirements  for  a  surface  on 
which  an  aircraft  can  travel  while  on  the  ground.  Ramps  and 
platforms  could  easily  be  constructed  which  the  android 
could  travel  over,  as  well.  A  ramp,  or  a  platform  was 
decided  as  a  highly  probable  necessity  to  facilitate  android 
maintenance  from  the  ground.  With  each  new  aircraft  type, 
the  relocation  of  its  components  is  feasible;  but  the 
relocation  on  existing  aircraft  is  limited.  Some  relocation 
will  be  required  to  facilitate  android  maintenance. 

The  android's  manipulators  are  of  the  same  class  as 
industrial  robots.  Good  manipulators  are  available  today, 
and  industry  continues  to  improve  them.  Some  manipulators 
have  limited  feedback  which  allows  more  precise  force  and 
movement  measurements.  Industrial  robots  are  available 
which  accomplish  pick  and  place,  as  well  as  the  insertion  of 
one  object  into  another.  This  is  possible  because  the  items 
to  be  picked  or  inserted  have  a  known  orientation  and 
position,  and  the  place  or  object  waiting  for  insertion  is 
also  well  defined  in  space.  These  manipulators  are 
currently  in  use  in  the  automobile  industry,  and  two  were 
were  demonstrated  by  Kohol  Systems,  Inc.  after  the  Robotics 
Seminar  held  in  Dayton,  Ohio  on  17  April  1982.  This  ability 
can  be  used  with  a  known  end  effector  for  some  aircraft 
maintenance  requirements. 

Joseph  Engelberger  in  his  article  on  "Robotics  in 


Practice:  Future  capabilities"  discussed  a  new  invention  in 

touch  sensing: 

The  second  most  important  frontier  is  tactile 
sensing  and  here  invention  has  already  occurred. 
Draper  Labs,  in  its  efforts  to  computer  control  the 
interaction  between  parts  that  must  be  mated,  came 
upon  a  serendipitous  conclusion  that  such 
parts-mating  can  be  eased  by  a  completely  mechanical 
passive  accommodation.  The  device  known  as  the 
Remote  Center  Compliance  (RCC)  is  ....  already  being 
used  experimentally  by  researchers  attacking  the 
problem  of  programmable  assembly  (Electronic,  1982: 

55). 

The  RCC  was  described  by  Whitney  and  Nevins  as 

a  controlled,  documented,  reproducible  source  of 
multi-axis  compliance  or  float  which  allow  easy 
interfacing  of  mechanical  mating  parts  in  spite  of 
intial  lateral  and  angular  misalignments.  Its 
greatest  potentials  lie  in  accomplishing  difficult 
insertions  and  in  providing  a  valuable  margin  of 
error  in  constructing  and  maintaining  many  kinds  of 
machines  (Whitney,  1979:  143). 

This  device  as  part  of  a  wrist  would  accomplish  many 

inserting  and  matching  requirements  for  aircraft 

maintenance.  Using  software-controllable  compliances  and 

saturation  levels  for  a  f ive-degree-of-freedom  wrist  as  a 

means  for  active  force  feedback,  more  precise  manipulator 

activites  could  be  accomplished.  This  'active  adaptive 

compliance  wrist*  was  described  in  the  literature  in  1979. 

It  was  reported  that  work  was  to  continue  to  improve  the 

wrist  by  using  stochastic  methods  to  provide  certain 

learning  functions.  The  paper  claimed  that  this  active 

adaptive  compliance  wrist  will 

allow  the  use  of  inaccurate  general  purpose 
industrial  robots  for  precision  assembly  tasks  (Van 
Brussel,  1979:  176). 

More  recently.  Shin  and  Malin  discussed  an  adaptive 
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feedback  control  algorithm  for  a  multiple  degree-of-freedom 
manipulator  which  they  claim  is  well  suited  to  real-time 
microprocessor  application.  The  crux  of  this  is  the  use  of 
a  microprocessor  for  each  degree-of-freedom  within  the 
manipulator  (Shin,  1981b:  420-427). 

But  very  delicate,  precise  work,  such  as  inspecting 
surface  tolerances,  requires  an  even  more  sophisticated 
touch  sense.  'Active  touch  sensing'  research  has  been 
conducted  at  the  Artificial  Intelligence  Laboratory  at  the 
Massachusetts  Institute  of  Technology  and  in  France  by 
Briot.  Both  use  a  planar  array  or  matrix  sensor.  Briot 
described  his  technique  in  1979,  as  an  'artificial  skin' 
sensor  (Briot,  1979:  529).  The  MIT  AI  Lab's  active  touch 
sensing  method  attached  its  array  of  tactile  sensors  to  a 
mechanical  finger.  The  finger  then  identified  "commonly 
used  fastening  devices-  nuts,  bolts,  flat  washers,  lock 
washers,  dowel  pins,  cotterpins,  and  set  screws"  by  pressing 
and  probing  the  object  with  the  finger.  The  finger  and 
sensor  combination  were  controlled  by  a  tactile  recognition 
program.  The  paper's  description  of  the  active  versus 
classical  sensing  approach  was  the  "choice  of  top-down 
versus  bottom-up".  The  classical  approach  was  "sense, 
analyze,  and  abstract"  while  the  active  approach  was 
"hypothesize,  measure,  analyze,  debug,"  and  repeat  until 
done  (Hillis,  1981:  23-24).  However,  the  author  of  the 
paper  remarked  that 

one  should  not  be  too  impressed  by  a  program  that 

distinguishes  between  six  objects  on  the  basis  of 
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three  parameters.  If  only  a  single  bit  of 
information  was  derived  from  each  parameter,  it 
should  be  enough  to  recognize  at  least  eight  objects 
( Hillis ,  1981:  32). 

The  remarks  continued  with  three  suggested  improvements 
which  (in  Hillis'  estimation)  were  not  too  far  in  the 
future.  These  were  texture  recognition,  thermal 
conductivity  sensing,  and  coordination  of  multiple  tactile 
images  into  a  global  picture  (Hillis,  1981:  33). 

Thus  the  major  android  manipulator  needs  were  1)  the 
ability  to  work  from  a  mobile  platform,  2)  the  interfaces 
between  the  manipulators  and  sensors,  3)  improved  closed 
loop  feedback  control,  and  4)  faster  data  processing  to 
produce  the  desired  capabilities.  It  must  be  remembered 
that  most  industrial  robots  are  bolted  to  the  floor  in  the 
areas  they  work  or  are  only  mobile  in  a  limited  sense.  Thus 
a  mobile  base  for  a  manipulator  introduces  additional  system 
control  problems  or,  at  least,  the  possibility  of  additional 
problems . 

In  fact,  these  problems  would  be  dealt  with  as  part  of 
the  'manipulator  strategy'.  Manipulation  strategy,  a 
subfunction  of  IC2,  determines  how  a  manipulator  will  do  a 
given  task.  In  general,  "manipulation  strategy  is  in  a  low 
state  of  development.  This  is  very  task  dependent.  Can 
strategies  be  developed  which  apply  to  a  class  of  tasks?" 
(Whitney,  1980:  156).  Again,  the  last  area  of  discussion 
is  IC2.  Part  of  IC2  is  communication.  Communication  is 
both  internal  and  external. 

To  accomplish  part  of  the  external  communication,  human 
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speech  recognition  is  needed.  Lt.  Jerry  Montgomery  wrote  an 
algorithm  which  took  the  output  of  an  acoustic  analyzer  and 
determined  what  word  was  spoken.  The  analyzer  had  a  set  of 
71  phonets,  of  which  two  were  noise  representations,  based 
on  the  words  zero,  one,  two  three,  four,  five,  six,  seven, 
eight,  nine.  The  recognition  rate  was  greater  than  ninety 
per  cent,  and  a  few  additional  words  outside  of  those 
original  ten  words  were  correctly  identified  as  well.  The 
recognition  was  both  speaker  and  acoustic  analyzer 
independent,  and  single  words  were  recognized  rather  than 
sentences  (Montgomery,  1982).  As  long  as  human  speech  to 
the  android  is  limited  to  a  few  single  word  commands,  then 
Lt  Montgomery's  recognition  algorithm  should  be  a  primary 
candidate.  It  does  need  some  improvements  in  terms  of 
processing  time,  computer  size,  and  memory  requirements  to 
run  the  algorithm.  This  algorithm  used  fuzzy  set  theory  in 
its  decision  making  process. 

Fuzzy  set  theory  and  its  related  disciplines,  such  as 
possibility  distributions,  fuzzy  logic,  fuzzy  programming, 
and  fuzzy  production,  are  frequently  used  to  provide  robots 
with  the  ability  to  make  judgemental  decisions.  Much 
development  and  research  is  needed  in  this  area  to  provide 
the  level  of  judgement  required  in  this  maintenance  android. 
For  example,  the  fuzzy  production  system  described  by  Whalen 
and  Schott  was  a  direct  application  to  financial 
investments.  But  the  concept  of  a  fuzzy  production  system 

is  promising  because  it  provides  a  direct  model  of 

human-like  qualitative  reasoning  about  variables 


over  a  broad  spectrum  from  exact  concepts ...  to  very 
vague  and  diffuse  concepts,  all  within  a  unified 
system  of  approximate  reasoning. ...  fuzzy  logic  is 
tolerant  of  situations  which  would  be  considered 
paradoxical  in  the  Aristotelian  logic... the  process 
of  judgemental  interaction  with  a  fuzzy  production 
system  is  well-suited  to  the  area  of  decision 
support  systems...  (Whelan,  1981:  653). 

These  decision  support  systems  are  to  be  implemented  on 
microprocessors  and  microcomputers  which  will  be  on  board 
the  android  or  will  be  accessible  to  the  android.  As  such, 
these  decision  processes  will  in  part  be  programmed 
algorithms.  Prade  and  Vaina  defined  'Fuzzy  HOS '  as  the 
fuzzy  extension  of  Higher  Order  Software  (HOS)  methodology 
and  discussed  the  notion  of  fuzzy  data  types  and  the  concept 
of  fuzzy  reliability.  These  appear  as  one  means  of 
specifying  fuzzy  systems  (Prade,  1980:  850-857).  If  fuzzy 
mathematics  are  to  be  used  to  give  the  android  judgemental 
capability,  then  fuzzy  data  types  and  fuzzy  reliability  are 
concepts  to  be  dealt  with.  Fuzzy  mathematics  deserve 
thorough  investigation). 

In  direct  connnection  with  the  software  requirements  for 
decision  making  is  a  need  for  determining  probabilities  (in 
the  stochastic  sense).  However,  when  dealing  with  imprecise 
variables  such  as  those  used  with  and  introduced  by  fuzzy 
set  theory,  a  better  descriptive  term  is  'possibility 
distribution'.  Zadeh  continued  his  work  in  fuzzy  sets  with 
a  discussion  of  the  theory  of  possibility  distribution 
defined  as  "the  fuzzy  set  of  all  possible  vaules  of  a 
variable"  (Zadeh,  1980:  242).  This  possibility  distri¬ 
bution  may  also  come  to  be  known  as  'fuzzy  distribution'. 
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Overall,  IC2  is  the  major  'frontier'  area.  Work  is 

being  done  in  control,  artificial  intelligence,  pattern 

recognition,  networking,  and  so  on.  Most  of  the  current 

work  uses  large  main  frame  computers  or  minicomputers.  As 

computer  technology  advances,  so  does  the  switch  to 

microcomputers.  The  current  limitations  of  the 

microcomputers  is  their  capacity,  and  speed.  But  these 

barriers  are  challenged  daily.  The  needs  here  are  faster 

algorthms,  accurate  pattern  recognition  with  less  required 

input  data,  the  ability  to  work  while  moving,  and  so  on. 

Graupe  and  Saridis  in  their  paper  on  intelligent  controls, 

defined  intelligent  contols,  thusly: 

Significant  results  have  been  accomplished  in  Speech 
Recognition,  Image  Analysis  and  Perception,  Data 
Base  Analysis  and  Decision  Making,  Learning,  Theorem 
Proving  and  Gains,  Autonomous  Robots,  etc.  The 
discipline  that  couples  these  advanced  methodologies 
with  the  system  theoretic  approaches  necessary  for 
the  solution  of  the  current  technological  problems 
of  our  societies  is  called  "Intelligent  Controls". 
Intelligent  Controls  utilize  the  powerful  high-level 
decision  making  of  the  digital  computer  with 
advanced  mathematical  modeling  and  synthesis 
techniques  of  system  theory  to  produce  a  unified 
approach  suitable  for  the  engineering  needs  of  the 
future  (Graupe,  1980:  80-81). 

Graupe  and  Saridis  discussed  a  "Hierarchical  Intelligent 
Control  approach"  which  consisted  of  three  levels  of 
controls:  1)  the  organization  level,  2)  the  coordination 
level,  and  3)  the  hardware  control  level.  They  propsed  this 
approach  as  a  "unified  theoretic  approach  of  cognitive  and 
control  systems  methodologies"  (Graupe,  1980:  83).  The 

authors  later  explained  that  this  method  was 


successfully  applied  to  the  control  of  a  general 
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purpose  manipulator  with  visual  feedback  and  voice 
inputs,  and  traffic  control  system  for  an  integrated 
urban  and  highway  environment  (Graupe,  1980:  84). 

Increased  interest  in  the  demands  which  robotic  systems 

have  placed  on  control  theory  is  shown  by  the  increasing 

amount  of  research  being  conducted  on  robotic  system  control 

and  the  related  papers  discussing  it.  Bejczy,  in  1980, 

discussed  control  theory  and  robotics  in  a  generalized 

manner.  The  robotics  areas  discussed  were  robot  arms,  robot 

hands,  and  robot  locomotion  systems,  without  reference  to  a 

specific  model.  He  summarized  the  control  issues  involved 

with  multi-level  robot  control  systems  into  two  groups:  1) 

hierarchical  control  schemes,  and  2)  control  logic  systems. 

1)  In  general,  the  possiblity  of  controlling 

multivariable  systems  efficiently  requires  the 
development  of  hierarchical  control  schemes.  The 
information  content  associated  with  the  different 
hierarchical  control  levels  creates  several  control 
system  design  problems  (Bejczy,  1980:  59). 

2)  Pattern  recognition  schemes,  decision  networks 
and  logic  calculations  are  entering  into  the 
feedback  paths  of  advanced  robot  control  systems. 

This  has  a  profound  effect  on  the  stability  and 
other  performance  characteristics  of  robot 
controls ....  The  central  issue  is  now  to  design 
control  logic  systems  that  provide  stable  and 
optimal  performance  in  the  domain  of  relevant  events 
[vice  the  classical  time  domain]  (Bejczy,  1980: 

64). 

Much  of  what  Bejczy  says  is  directly  applicable  to  or 
extendable  to  the  android  control  problem.  He  also 
recognized  the  need  "to  study  and  develop  theoretical  frames 
for  the  analysis  and  synthesis  of  pattern-referenced  robot 
control  systems  (Bejczy,  1980:  65). 

For  now,  the  desired  control  system  approach  is  that  of 
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a  hierarchical  control  system.  This  is  the  literature's 
most  commonly  chosen  method  of  overall  robot  control.  Shin 
and  Malin  described  a  hierarchically  distributed  robot 
control  system  which  is  supposed  to  be  flexible  enough  to 
accomodate  the  integration  of  visual  and  tactile  sensing. 
However,  the  paper  stated  these  two  aspects  had  not  yet  been 
implemented  (Shin,  1980:  814).  James  Albus,  the  National 
Bureau  of  Standards,  has  co-authored  several  papers  on 
hierarchical  control  in  robots,  as  well. 


The  next  generation  of  robot  systems  will  be 
distinguished  from  present  second  generation  systems 
by  the  fact  that  the  operator  will  communicate  to 
the  robot  the  goals  that  are  to  be  achieved,  rather 
than  defining  the  sequence  of  operations  to  be 
performed.  From  a  description  of  the  desired  goal, 
the  robot  will  automatically  formulate  the  required 
plan  of  action.  In  order  to  generate  these  plans, 
robots  will  have  to  be  instilled  not  only  with  much 
greater  intelligence,  but  also  much  more  knowledge 
about  the  objects  to  be  manipulated.  Work  to 
develop  such  systems  is  already  underway  [Will, 
Lozano-Perez ]  (Shimano,  1980:  211). 

In  summary,  primitive  sight  and  hearing  mechanisms  are 
currently  available  to  give  the  android  those  perceptive 
abilities.  Also  currently  available  are  the  remote  center 
compliance  devices  and  active  touch  sensing  devices  which 
are  primitive  touch  mechanisms.  Manipulators  of  greatly 
varying  sizes,  shapes,  and  capabilities  are  available.  The 
technology  for  tracked  vehicles  is  sufficient  to  meet  the 
android's  mobility  needs.  The  limited  availabilities  lie 
with  the  IC2  area.  And  that,  is  where  the  current  state  of 
the  art  for  androids  and  robots  is  at  this  time. 
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IV.  Areas  Requiring  Further  Research 


Background 

The  approach  to  the  recommended  areas  requiring  further 
research  (frequently  referred  to,  in  this  thesis,  as  the  R&D 
program)  is  broken  down  into  functional  areas,  just  as 
Chapter  Three  is.  This  is  necessary  since  an  expert  in  one 
field  would  not  necessarily  be  an  expert  in  another  field, 
let  alone  be  an  expert  in  every  field  involved  in  android 
development.  However,  communication  and  understanding  must 
be  emphasized.  When  one  field  impinges  on  another,  each 
field  must  know  what  the  other  has  and  has  not  done.  This 
does  not  guarantee  a  successful  interfacing  of  the 
technologies,  but  does  make  success  more  probable.  This 
requires  a  "central"  overseer  who  provides  coordination, 
impetus,  encouragement,  and,  on  occasion,  a  'shove'  to  the 
various  groups  and  agencies  for  cooperation  and 
communication . 

Several  aspects  of  research  and  development  are  common, 
regardless  of  the  area  or  field  of  work  involved.  This 
program  is  no  different.  The  current  state  of  the  art  must 
be  assessed.  Items  available  off  the  shelf  must  be 
evaluated.  The  needs  required  to  meet  the  desired  goals 
must  be  defined. 


Once  these  three  aspects  are  assessed  and  compared, 
voids  can  be  clearly  identified.  Research  initiatives  are 


then  defined  to  fill  the  voids.  Those  shelf  items  requiring 
modification  must  be  evaluated  for  cost  effectiveness. 
Shelf  items  not  requiring  modifications,  and  other  needed 
supplies  or  items  must  be  procured. 

As  important  as  these  aspects  are,  for  a  successful 
android  or  robotic  project,  the  three  "C's"  ( 3Cs )  must  be 
adhered  to,  religiously!  Communicate,  cooperate,  and 
coordinate  are  the  3Cs  referred  to  by  this  thesis.  No  one 
area  should  be  developed  in  isolation  from  the  others.  A 
functional  android  requires  parts  which  interact,  interface, 
and  communicate  efficiently  together.  Thus,  an  android 
should  be  thought  of  as  a  holistic  mechanism.  That  is,  the 
parts  which  work  well  separately,  work  even  better  once  they 
are  joined  together  to  form  a  whole  mechanism.  In  fact,  due 
to  the  multiple  interfacings,  interactions ,  and  extended 
communications  the  joined  parts  work  at  a  level  which  is 
above  the  improvement  due  to  just  the  parts  cooperating. 

This  is  why  it  is  so  important  for  the  interaction, 
interfacing,  and  communication  not  to  be  haphazard.  Each 
part  grows  and  develops  somewhat  on  its  own.  But  even  so, 
the  other  android  parts  and  the  overall  goals  must  be 
considered  during  that  growth  period  as  well.  Then  as  these 
parts  eventually  become  the  whole  android,  the  whole  android 
will  be  a  holistic  mechanism. 

This  subject,  generically  called  robotics,  and  the 
interest  it  generates,  is  growing  significantly  each  day. 
By  the  time  this  thesis  is  published,  and  the  follow  on  work 
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begun,  a  new  survey  of  the  state  of  the  art  and  of  the  off 
the  shelf  items  will  have  to  be  made  for  each  area  to  be 
investigated  because  of  these  rapid  advances.  Thus,  each 
functional  area  will  have  to  have  its  own  literature  review 
prior  to  beginning  actual  research  in  that  area.  In 
addition  to  the  literature  review,  some  items  may  be 
obtainable  directly  from  robotic  parts  sources.  These  parts 
sources  are  also  rapidly  becoming  more  plentiful.  A  few  are 
listed  in  Appendix  E,  'List  of  Contacts  and  Suggested 
Contacts ' . 

The  items  available  in  this  manner  will  have  to  be 
reviewed  and  evaluated  for  their  applicability  to  the  given 
area  of  interest.  Based  on  the  information  gathered  by 
these  two  surveys,  the  decision  can  then  be  made  as  to 
whether  or  not  the  desired  capabilities  exist  or  if  further 
research  is  required  to  achieve  those  capabilities. 

A  thorough  study  of  the  various  aircrafts  within,  and 
proposed  for,  the  Air  Force  inventory  must  be  made  to  define 
the  classes  or  types  of  robots  and  androids  required.  This 
study  would  include  precisely  what  maintenance  is  done  and 
how  it  is  done  for  each  aircraft.  Studies  based  on  related 
fields  are  needed  for  their  descriptions  as  well,  such  as 
the  bioengineering  functional  descriptions  of  perception, 
processes,  and  manipulations. 

These  studies  are  based  on  how  people  do  the  work.  The 
results  of  these  studies  are  then  analyzed  and  transformed 
into  what  and  how  a  mechanism  efficiently  and  effectively 


accomplishes  them.  The  results,  of  the  analyses  and 
transformations,  determine  what  type,  and  how  many  androids 
or  robots  will  be  built.  Another  outgrowth  of  these  studies 
would  be  the  recommended  aircraft  component  design  and 
placement  modifications  to  aid  android  maintenance. 

These  studies  and  analyses  will  require  personnel  who 
are  expert  electrical  engineers,  digital  engineers, 
mechanical  engineers,  computer  engineers,  computer 
scientists,  bioengineers,  roboticists,  aircraft  maintenance 
personnel,  and  so  on.  Not  only  do  they  need  to  be  experts 
in  their  own  areas  but  they  should  have  an  interest  or 
capability  in  robotics.  This  is  necessary  to  allow  the  3Cs 
to  work. 

Some  duties  or  categories  of  duties  are  common  from 
aircraft  to  aircraft.  Thus,  the  idea  of  classes  or  types  of 
maintenance  robots  and  androids  is  very  feasible.  This  idea 
also  has  the  direct  side  benefit  of  robots  doing  simple, 
menial  tasks  in  maintenance  shops  relatively  soon.  This 
early  implementation,  in  turn,  allows  the  maintenace 
personnel  to  get  used  to  having  an  android  or  robot  around, 
while  the  designers  get  some  early  field  testing  and  much 
needed  feedback  from  the  maintenance  personnel. 

One  expected  outgrowth  of  these  studies  is  an  android  or 
robot  which  is  independent  of  aircraft  type.  For  example,  a 
mobile  robot  could  fetch  forgotten  tools  or  tool  boxes, 
check  the  grounds  for  foreign  matter  and  remove  it,  and  make 
routine  security  checks  for  unauthorized  personnel  or 
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objects,  or  even  do  snow  removal  around  hangar  doors.  If  it 
never  touches  the  aircraft,  but  merely  gathers  information 
such  as  the  aircraft  type,  mission,  and  identification  in 
addition  to  those  other  duties  just  listed,  then  the  robot 
or  android  is  aircraft  independent.  It  then  does  menial  but 
necessary  labor,  provides  communication  and  information  for 
other  robots,  androids,  and  people  while  allowing 
maintenance  personnel  and  more  sophisticated  robots  and 
androids  to  do  other  work  more  effectively,  efficiently,  and 
safely.  It  would  also  minimize  the  duties  a  more 
sophisticated  android  or  robot  would  have. 

Areas  Requiring  Further  Research 

At  this  time,  the  program  is  based  on  the  android 
capabilities  and  the  current  state  of  the  art  as  discussed 
in  Chapter  Three.  The  steps  common  to  all  research  efforts 
are  listed  first,  then  each  functional  area  is  presented. 
This  program  assumes  that  all  of  the  aircraft  maintenance 
procedures  for  all  of  the  Air  Force's  inventory  were 
studied,  and  that  the  classes  of  robots  and  androids  have 
been  defined. 

Common  Steps.  As  each  functional  area  is  chosen  by 
someone  for  research,  the  following  questions  must  be 
answered . 

1.  Are  the  goals  given  in  this  thesis  still  valid? 

a.  What  are  the  changes? 

b.  Are  the  changes  significant? 
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2.  What  is  the  current  state  of  the  art? 

3.  What  is  available  as  shelf  stock? 

4.  Comparing  1.  with  2.  and  3.,  what  are  the  current  needs? 

a.  Are  there  still  voids  requiring  research? 

b.  How  much  research  effort  will  be  required? 

c.  Is  the  shelf  stock  suitable? 

d.  Is  modification  of  shelf  stock  cost  effective? 

e.  Should  a  special  manufacturing  requirement  be  made, 
instead  of  modifying  shelf  stock? 

f.  Is  the  shelf  stock  easily  interfaced  to  other 
components? 

g.  Can  other  components  be  easily  designed  or 
redesigned  to  interface  better  with  the  shelf  stock  to  be 
used? 

h.  At  this  time,  are  further  changes  in  the  current 
model  cost  effective,  or  would  incorporating  the  innovations 
in  a  later  model  be  more  cost  effective? 

i.  Have  you  continuously  applied  the  3Cs? 

5.  What  are  the  wartime  hazards? 

a.  What  about  bullets  and  schrapnel,  blast  and  thermal 
radiation? 

b.  What  about  radiation  effects,  both  direct  and 
indirect? 

c.  What  about  the  chemicals  used  in  both  chemical 


warfare  and  in  defense  (from  fire  extinguishers  to 
anti-chemical  warfare  chemicals)? 


IC2.  IC2  requires  the  most  work.  It  has  the  highest 
priority  of  the  functional  areas.  IC2  affects  all  of  the 
functional  areas  and  is  the  single  most  critical  area  of 
all,  for  the  android.  Control  theory  and  practice  will  have 
to  be  extended  and  developed.  Sturdier  and  more  mobile 
hardware  will  have  to  be  developed.  Internal  sensing  and 
communications  will  have  to  be  improved  in  speed, 
sturdiness,  and  compactness. 

More  specifically,  smaller,  faster,  more  durable 
processors  are  needed.  The  algorithms  which  allow  experts 
to  pass  on  their  judgemental  capabilities  to  the  android,  as 
well  as  those  algorithms  which  provide  the  artificial 
intelligence,  control  and  communication  must  be  improved 
and,  in  some  cases,  developed  from  scratch.  This  is  the 
first  frontier  for  androids.  Without  resounding  success 
here,  success  in  the  other  areas  is  limited.  IC2  must  do 
all  of  this,  and  meet  the  common  research  needs  stated 
previously. 

Perception.  Perception  is  the  second  most  important 
functional  area.  The  needs  of  IC2  overlap  the  perception 
needs.  These  needs  in  perception  are  limited  to  the  sensors 
and  sensory  applications,  rather  than  applied  to  the  whole 
android.  [ IC2  is  applied  to  the  whole  android.]  Again,  the 
processors  and  algorithms  associated  with  the  sensors  need 
to  be  faster,  more  compact,  and  able  to  meet  the  common 
research  requirements  described  earlier. 

The  pattern  recognition  capabilities  need  to  be 


improved.  The  sensors  need  to  supply  accurate  data  while 
moving.  Also,  if  remote  sensors  are  needed,  then  the  means 
to  receive  data  from  these  remote  sensors  in  a  timely  manner 
must  also  be  developed.  Sensors  need  to  be  miniaturized  and 
reliable.  The  data  output  by  the  sensors  needs  to  be  easily 
useable  by  the  pattern  recognition  algorithms.  The  types  of 
perception,  in  their  order  of  priority,  are  speech,  touch, 
and  vision.  This  is  also  the  order  based  on  the  amount  of 
work  needed  in  that  area  for  success.  [Remember,  human  type 
vision  is  not  considered  feasible  in  the  foreseeable 
future. ] 

Manipulators.  As  listed  above  for  IC2  and  perception, 
manipulators  have  some  common  needs:  good  algorithms,  the 
ability  to  function  from  a  non-fixed  base,  fast  and  compact 
processors,  interfacing  capabilities,  and  the  ability  to 
meet  the  common  research  requirements  described  previously. 
The  development  of  interchangeable  end  effectors  and  the 
resulting  IC2  interfaces  (could  be  a  problem)  has  need  of 
the  most  effort  in  this  area.  Within  the  functional  area  of 
manipulators,  the  interchangeable  end  effector  and  its 
interfaces  has  top  priority. 

Mobility.  As  listed  for  the  three  previous  functional 
areas,  mobility's  greatest  need  is  for  work  on  the  mobility 
applications  of  IC2.  This  area  was  given  the  lowest 
priority  because  the  desired  technology  is  primarily 
available.  The  algorithms  which  provide  the  intelligence 
and  control  functions  are  actually  part  of  IC2.  Ensuring 
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IC2  for  mobility  is  accomplished  and  meeting  the  common 
research  requirements  described  previously,  is  all  that  is 
left  to  be  done  in  this  functional  area. 

What  Can  Air  Force  Agencies  Do? 

The  Air  Force  agencies  discussed  here  are  AFIT,  and 
AFAMRL  with  general  recommendations  for  other  Air  Force 
agencies.  The  discussions  are  kept  at  a  general  level,  with 
specific  recommendations  made  in  Chapter  Six,  'Conclusions 
and  Recommendations  1 . 

AFIT.  AFIT  is  a  tremendous,  and  frequently  untapped, 
source  of  manpower.  All  three  schools  have  access  to  large 
numbers  of  'free  labor'.  The  Engineering  School  and  the 
school  of  Systems  and  Logistics  have  students  in  residence 
for  relatively  long  periods  of  time.  Their  thesis  students 
have  curriculums  ranging  from  12  to  18  months.  For 
robotics,  the  Engineering  School  will  provide  the  most 
resources,  although  the  Log  School  does  have  Engineering 
Management  students  who  could  easily  have  the  background  and 
interest  to  work  in  some  areas.  Another  school,  commonly 
forgotten,  is  the  School  of  Civil  Engineering.  The  School 
of  Civil  Engineering's  resident  students  are  primarily  short 
course  students.  However,  some  of  the  courses  require 
students  do  special  projects  as  a  group.  Thus,  it  is 
possible  that  some  small  managerial  or  technical  design 
problems  could  be  done  by  a  group  of  Civil  Engineering 
students,  such  as  a  physical  requirements  definition. 


Thus  students  could  easily  tackle  and  solve  small 
problems  requiring  one  man-month  to  one  man-year  of  work. 
Students  are  well  able  to  do  literature  surveys  and  reviews 
with  constructive  comments  and  thoughts.  The  same  is  true 
for  checking  what  is  available  as  off  the  shelf  items. 
Students  are  willing  to  do  special  projects  as  part  of  a 
laboratory  class,  or  as  a  one  or  two  term  special  study,  or 
even  as  a  full  thesis  effort.  Most  students  want  to  do  work 
which  is  interesting  and  which  challenges  and  stimulates 
their  imaginations.  Probably  most  important,  students  are 
willing  to  'break  their  backs'  if  they  truly  believe  the 
work  they  are  doing  is  useful,  and  not  just  an  academic 
exercise! 

The  'management*  of  AFIT  can  encourage  this.  The 
Engineering  School  should  offer  courses  in  robotics  and  its 
related  fields,  and  establish  a  program  in  this  area,  as 
well.  This  should  be  a  resident  program  and  a  continuing 
education  program.  With  a  resident  robotics  program, 
students  would  have  a  better  robtics  background  from  which 
to  do  thesis  work.  The  continuing  education  program  would 
allow  the  training  and  familiarization  of  Air  Force 
personnel  in  robotics.  This  is  needed  if  the  Air  Force  is 
going  to  work  in,  or  monitor  contracts  which  make  the  robots 
or  androids,  or  if  the  Air  Force  is  going  to  use  the  robots 
or  androids  once  they  are  developed.  AFIT  and  its  students 
could  do  very  valuable  research  and  development  for  the  Air 
Force  in  robotics  with  some  financial  backing  for  research, 


for  instructors,  and  for  classes.  Once  an  agency  decides  to 
be  involved  with  robotics,  it  defines  what  it  will  do.  It 


then  has  to  break  that  definition  into  smaller,  more 
workable  pieces.  Some  of  these  pieces  and  subpieces,  APIT 
could  do  for  the  agency.  Thus  the  agency  involved  would 
sponsor  and  support  (with  money,  manpower,  material,  etc) 
special  projects  and  thesis  efforts. 

Just  as  AFIT  has  a  continuing  pattern  recognition 
research  laboratory,  there  could  be  other  continuing  efforts 
in  robotic  control  research,  artificial  intelligence 
research,  and  so  on  throughout  the  functional  areas  needed 
for  robotics.  But  this  requires  manpower  and  funding  for 
the  school  to  do  this. 

AFAMRL .  The  Air  Force  Aerospace  Medical  Research 

Laboratory  and  its  Modeling  and  Analysis  Branch 

had  a  program  in  areas  of  bionics,  cybernetics, 
artificial  intelligence,  pattern  recognition  and,  to 
some  extent,  robotics  a  number  of  years  ago.  These 
programs,  by  specific  directives,  were  discontinued, 
with  total  technical  withdrawal  occurring  in  the 
mid-70s.  Recent  Air  Force  top-level  guidance, 
however,  has  revived  these  technological  areas  and 
encouraged  new  program  initiatives.  In  response  to 
these,  our  laboratory  has  sought  to  define  its  role 
within  these  technological  areas  as  well  as  to 
simultaneously  focus  on  a  specific  applications 
scenario.  This  latter  being  the  development  of 
robotic  techniques  for  servicing  aircraft  in 
hazardous  environments  (Kaleps,  1982). 

Assuming  the  Air  Force  supports  AFAMRL' s  mission,  it  can 

resume  its  previous  efforts  as  applicable  to  the  desired 

goal  described  in  Chapters  Two  and  Three.  As  these  efforts 

are  resumed,  there  will  be  areas  which  would  fall  under  the 

capabilities  of  AFIT.  Since  AFAMRL  and  AFIT  are  physically 
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located  near  each  other,  AFAMRL  could  easily  support 
projects  done  at  AFIT  with  personal  guidance,  resources,  and 


money  for  those  projects  of  interest  to  AFAMRL. 

On  the  broader  scene,  work  will  have  to  be  done  at 
AFAMRL  to  evaluate  what  can  be  done  by  themselves,  in  house, 
and  what  would  have  to  be  contracted  out.  Additionally, 
ATAMRL  needs  to  maintain  contact  with  private  industry  and 
other  Air  Force  agencies  as  to  what  is  being  done,  by  whom, 
and  where.  This  is  done  of  course,  by  attending 
conferences,  reading  the  literature,  and  through  personal 
contacts.  But,  AFAMRL  can  also  sponsor  workshops,  meetings, 
and  conferences  bringing  the  experts  from  the  various 
disciplines  together.  As  the  different  disciplines  come 
together  frequently,  then  the  intercommunication  becomes 
easier.  Thus,  the  3Cs  could  be  implemented  more  easily,  as 
well . 

Wright  Patterson  AFB  has  many  agencies  involved  in 
robotics  and  related  areas  such  as  ICAM  (Integrated 
Computer-Aided  Manufacturing)  and  CAD-CAM  (Computer-Aided 
Design  Computer-Aided  Manufacturing).  It  is  surprising  just 
how  many  different  offices  are  involved.  Some  of  these  are 
listed  in  Appendix  D.  A  monthly  luncheon  seminar  with  local 
speakers  or  discussions  of  non-classif ied  material  would 
also  help  the  3Cs  to  grow  and  be  implemented,  at  least  on 
the  local  base  level. 

Other  Air  Force  Agencies .  In  as  much  as  their  current 
or  revised  mission  statements  allow,  other  agencies  shou'd 
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think  of  what  they  are  doing  which  could  contribute  to  the 
growth  of  robotics.  Those  agencies  not  research  oriented, 
should  think  in  terms  of  what  could  be  done  by  a  robot  or  an 
android  and  what  would  be  'nice'  for  a  person  not  to  have  to 
do.  Managers  should  not  think  of  robots  or  androids  as 
replacing  people  in  the  sense  that  people  will  be  lost.  But 
they  should  think  of  robots  and  androids  as  a  meins  of 
protecting  their  people  from  harm  in  dangerous  situations, 
or  of  relieving  them  of  drudgery  that  no  one  really  likes  or 
wants  to  do.  Those  are  the  situations  and  times  that  robots 
or  androids  are  needed,  not  to  replace  humans  at  what  they 
enjoy  doing! 

Not  only  that,  but  in  war,  if  robots  can  do  what  people 
do,  and  do  it  well,  then  by  combining  people  and  robots  or 
androids  would  allow  needed  resources  to  be  dispersed. 
Dispersed  resources  are  more  costly  for  the  enemy  to 
destroy.  For  example,  assume  an  airfield  requires  20 
maintenance  troops  to  be  on  hand  to  handle  the  wartime 
aircraft  maintenance,  and  assume  that  one  android  can  do  the 
work  of  one  person.  Then,  if  20  androids  were  available,  by 
putting  10  people  and  10  androids  together,  there  would  be 
enough  maintenance  'personnel'  to  man  two  airfields.  The 
second  set  of  personnel  could  be  sent  to  one  of  Civil 
Engineering's  'portable'  airstrips.  This  provides 
additional  places  for  the  aircraft  to  be,  forcing  the  enemy 
to  expend  more  energy  and  resources  to  destroy  our 


resources . 


Mobile  Platform  Project 


Over  the  past  several  years  at  AFIT,  various  short-term, 
robotics  oriented  projects  were  tackled.  The  time  spent  on 
each  project  varied  from  weeks  to  several  months.  Many 
aspects  and  results  of  these  efforts  were  sucessful.  Some 
were  directly  applicable  to  this  mobile  platform  project 
while  others  were  peripheral.  Inititally,  the  physical 
results  and  documentation  of  these  previous  efforts  were 
gathered.  Once  gathered,  it  was  obvious  that  some 
organization  and  sorting  was  required  to  determine  what  was 
of  value  to  the  immediate  project  and  goal. 

Some  of  the  documentation  was  very  useful  and 
informative.  Unfortunately,  most  had  little  direct  bearing 
or  else  required  much  work  to  discover  what  was  or  was  not 
useful.  As  part  of  a  previous  effort  the  mobile  platform 
had  been  constructed.  Since  an  economical  mobile  platform 
could  not  be  found  in  time  for  this  project,  it  was  decided 
to  continue  using  this  platform.  An  MMD-1  microcomputer  had 
been  associated  with  this  platform  in  a  previous  project, 
and  considering  the  resource  constraints  its  use  was 
continued  also.  The  MMD-1  executes  8080  code.  Thus,  if  an 
upgrade  to  a  better  microcomputer  chip  at  a  later  date 
included  this  capability  then  all  the  existing  computer  code 
would  be  useable  with  the  new  microcomputer .  With  an 
appropriate  compiler,  code  could  be  developed  in  a  higher 
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order  language  such  as  FORTRAN  or  PASCAL. 


The  AFIT  MMD-l/MI  configuration  had  2.5K  of  user 
accessible  "on  board"  memory.  This  configuration  also 
allowed  the  use  of  an  ADM-3  CRT  terminal,  and  cassette 
recorder  for  nonvolatile  memory.  This  nonvolatile  memory 
was  necessary  when  working  with  an  MMD-1 ,  since  loss  of 
power  meant  a  loss  of  memory.  The  MMD-1  also  required  hand 
keying  in  of  programs,  since  downloading  from  a  higher  order 
machine  was  not  avaliable.  The  tape  recorder  allowed  long 
programs  to  be  stored  on  tape,  and  then  reloaded  into  memory 
from  tape.  Maj  Borky,  a  past  professor  at  AFIT,  had  used 
the  CRT  terminal  and  cassette  recorder  with  an  MMD-1  while 
at  AFIT.  However,  little  documentation  was  available  on  how 
he  was  able  to  get  the  setup  working.  All  that  was  known 
was  that  he  had  used  the  three  pieces  of  equipment  together. 

Many  hours  were  spent  discovering  how  to  get  these  three 
major  pieces  of  hardware  communicating  properly  with  each 
other.  As  a  result,  the  code  given  in  Appendix  C  was 
generated.  These  programs  included  a  bootstrap  loader 
routine,  a  write  to  the  cassette  recorder  (from  the  MMD-1 
memory)  routine,  and  a  read  from  cassette  recorder  (to  the 
MMD-1  memory)  routine.  The  bootstrap  loader  was  the  minimal 
code  hand  keyed  into  the  MMD-1  which,  when  executed,  loaded 
code  from  the  tape  into  the  MMD-1  memory.  Thus,  it  works 
similarly  to  a  disk  bootstrap  loader.  Several  other  useful 
routines  were  written  or  modified  which  helped  to  implement 
the  above  mentioned  routines.  Some  of  these  other  routines 


were  a  time  delay  routine,  a  display  routine  (which 
displayed  the  memory  contents  on  the  MMD-1  LEDs),  and  a 


return  to  the  CRT  monitor  control  routine. 

Additionally,  extra  copies  of  the  MMD-l/MI  and  EID-1 
operating  manuals  and  EID-1  laboratory  experiments  were 
collected  and  annotated  to  reflect  the  special  AFIT 
configuration  and  the  special  data  collected  while 
accomplishing  this  project.  The  manuals  were  not  included 
in  this  thesis  since  they  reflect  a  system  unique  to  AFIT. 
However,  they  do  exist  at  AFIT  for  future  reference  by  those 
doing  follow  on  work  at  AFIT. 

Once  communication  was  established  between  the  MMD-1  and 
its  peripherals,  work  progressed  on  making  the  platform 
move.  The  first  movement  goal  was  to  find  motors  which 
would  turn  the  wheels  while  attached  to  the  platform.  The 
wheels  were  acceptable  (vice  the  recommended  tank  tracks  for 


the  ’ultimate’ 

android)  since 

the 

platform ’ s 

current  and 

near  future 

movement  will 

be 

restricted 

to  building 

corridors  and  rooms  which  have  level,  smooth  floors. 

The  previous  effort  tried  stepper  motors,  since  it  was 
felt  they  would  be  easier  to  interface  to  a  digital  computer 
for  computer  control.  However,  the  specification  sheet  for 
the  stepper  motors  stated  that  the  torque  (per  motor)  was  a 
maximum  of  43  oz.-in.  The  suggested  uses  for  these  motors 
were  chart  drives,  X-Y  plotters  and  paper  feed  drives. 
Needless  to  say,  the  motors  could  not  move  the  mass 
combination  of  the  platform,  motors,  and  wheels.  The 
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estimated  combined  weight  was  35  pounds. 


Extensive  searching  (via  letters  and  telephone  calls) 
discovered  a  small  DC  motor  with  a  starting  torque  of  75.0 
in. -lbs.  and  a  running  torque  of  21.0  in. -lbs  at  16.0  RPM. 
No  specification  sheet  came  with  the  motors,  this  data  was 
provided  in  the  catalog  where  the  motors  were  found.  A  copy 
of  this  catalog  page  was  provided  in  Appendix  P.  Two  motors 
were  purchased,  one  for  each  wheel.  The  motors  were  mounted 
on  the  platform  and  attached  to  the  wheels.  Each  motor  was 
connected  directly  to  the  DC-power  source  to  test  the 
motors.  One  motor  turned  the  platform  in  a  circle  using  the 
stationary  wheel  as  a  pivot  point.  Maj  Ross  then  sat  on  the 
platform  and  repeated  the  test.  The  single  motor  again 
turned  the  platform  in  a  circle,  pivoting  around  the 
stationary  wheel.  The  current  measurements  were  not  taken 
at  this  time,  but  were  taken  later,  in  July  1982  to 
determine  the  current  drawn.  The  power  source  used  for 
these  tests  was  not  a  battery,  but  a  constant  DC  power 
source  which  used  a  normal  120-volt  AC  socket. 

The  estimated  weight  of  Maj  Ross,  and  the  platform  was 
two  hundred  pounds.  Since  one  motor  could  move  two  hundred 
pounds  (with  the  AC-powered  DC  power  source),  it  was  felt 
that  the  platform  should  be  able  to  carry  the  weight  needed 
with  both  motors  running.  While  waiting  for  the  12-volt  DC 
(car  type)  battery  to  be  found  and  charged,  a  simple  motor 
controller  was  designed  (by  Dr.  Jones)  and  built.  The  motor 
controller  design  was  based  on  gross  current  measurements 
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made  in  July  1982.  The  current  was  1.2  amps  (approximate) 
while  running  and  3.5  amps  (approximate)  when  stalled.  The 
actual  current  readings  were  not  steady,  but  were  always 
less  than  the  values  reported  above.  The  motor  controller 
diagram  was  presented  in  Figure  3. 


The  normal  tolerance  in  color  coded  resistor  values  was  used 
to  balance  the  two  motors’  voltage  output  through  the  motor 
controller.  This  resistor  tolerance  was  five  per  cent.  The 
motors  were  not  identically  matched.  The  drift  introduced 
by  this  slight  mismatching  of  the  motors  was  acceptable 
during  these  initial  stages.  Both  motors  were  operated  from 
the  same  power  source,  with  the  voltage  passing  through  a 
motor  controller  for  each  motor.  These  motor  controllers 


minimized  the  inherent  differences  between  the  two  motors. 


(Later,  the  drift  was  minimized  even  more  by  use  of  a  second 
input  signal  controller,  i.e.  each  motor  had  its  own  input 
control ) . 

A  variable  speed  was  desired,  so  a  simple  input  signal 
controller  was  designed  (by  Dr.  Jones)  and  constructed  as 
shown  in  Figure  4. 


Figure  4.  Input  Signa±  Controller 


This  allowed  the  motor  controller  output  to  be  varied 
depending  upon  the  output  of  the  input  signal  controller. 
This  control  was  manual  by  using  a  variable  resistor,  but 
this  was  the  "hook"  to  allow  the  MMD-1  to  control  the  motor 
speed.  By  replacing  the  circuit  of  Figure  4  with  a  D/A 
signal  converter,  the  MMD-1  could  control  the  motor  speed. 
The  output  voltage  of  this  controller  was  0  ->  9  volts. 
Initially  one  input  signal  controller  was  constructed  and 
used  to  control  both  motors  simultaneously.  Once  one  input 
signal  controller  worked,  a  second  was  built  and  installed, 
so  each  motor  was  controlled  independently.  The  dual  input 


signal  controllers  minimized  the  drift  due  to  unmatched 
motors  even  more. 

The  motors  worked  and  were  controllable  while  receiving 
power  from  the  constant  DC-power  source.  Next  the  motors 
and  controllers  were  tested  with  the  battery  as  the  power 
source.  Thus,  the  platform  was  independently  powered  and  by 
replacing  Figure  4  with  the  appropriate  D/A  signal 
converter,  the  platform  could  be  connected  to  the  MMD-1  for 
computer  control.  A  previous  effort  had  established  the 
means  for  operating  the  MMD-1  from  a  12-Volt  battery 
(Meisner,  1981).  This  operability  was  not  verified  as  part 
of  this  project.  The  next  task  verified  whether  the  battery 
operated  platform  could  support  the  weight  of  an  individual. 
As  currently  configured,  with  the  controllers  shown  in 
Figures  3  and  4,  the  platform  would  not  move. 

The  capability  to  carry  an  individual  was  not  required, 
however,  the  requirement  was  for  the  platform  to  move  with 
100  pounds  of  equipment  and  related  devices  attached  to  it. 
This  100  pounds  represented  the  additional  features  which 
might  be  added  and  tested  at  a  future  date,  such  as 
manipulators,  visual  sensors,  additional  communication, 
control  and  intelligence  features,  and  so  on.  Since  it  was 
difficult  and  inconvenient  to  find  and  weigh  objects  to  a 
total  weight  of  100  pounds,  a  'quick  and  dirty'  test  using 
an  individual  was  tried.  The  conclusion  was  that  if  the 
platform  could  move  with  an  individual  (at  least  100  pounds) 
then,  the  platform  would  suffice  for  the  future  equipment 


testing  expansion  requirement. 

Not  only  would  the  platform  not  move  with  the 
individual  on  top,  but  when  the  individual  got  off,  the 
platform  still  would  not  run.  When  directly  connected  to 
the  battery,  the  motors  still  worked.  Apparently,  the 
current  required  for  such  a  load  was  too  much  for  the  input 
signal  controllers  as  designed.  Since  the  input  signal 
controllers  were  to  be  replaced  by  D/A  signal  converters, 
the  controllers  were  not  improved  to  handle  the  current 
requirements.  This  will  be  of  significance  to  whoever 
designs  the  D/A  signal  converter,  however. 

The  AFIT  School  of  Engineering  had  a  graduate  student 
who  designed  an  electric  vehicle  power  controller  as  his 
thesis  (Frazier,  1981).  Captains  Clark  Briggs  and  Aaron 
DeWispelare  (Astro/Aeronautical  Engineering  Department) 
brought  this  thesis  document  to  my  attention.  At  this 
stage,  this  controller  was  more  elaborate  than  necessary. 
However,  as  the  platform  develops  more  and  more  in 
capabilities,  improved  motors,  or  both,  this  controller 
(with  or  without  modifications)  may  prove  very  worthwhile. 

Thus,  the  platform  moves  on  its  own  and  can  have  the 
computer  "brain"  added  as  a  later  project.  Other  features 
could  be  added  as  they  are  developed  or  become  available. 
The  following  chapter,  "Recommendations  and  Conclusions", 
provides  more  detail. 


VI.  Recommendations  and  Conclusions 


Discussion 

This  thesis  consists  of  two  parts,  a  theoretical  portion 
which  results  in  the  recommended  areas  for  further  research 
program  as  presented  in  Chapter  IV,  and  a  practical  hardware 
project,  presented  in  Chapter  V.  The  theoretical  problem 
studied  was  the  development  of  a  program  from  which  a 
detailed  R&D  plan  could  be  prepared.  This  R&D  plan,  if 
carried  through,  would  result  in  a  mechanism  which  would 
provide  aircraft  maintenance  in  a  hostile  or  hazardous 
environment  without  direct  human  supervision. 

The  initial  work  was  a  literature  survey  to  see  if  this 
had  been  done  previously  and  whether  or  not  it  had  been 
documented.  Various  people  involved  with  the  robotics  field 
were  interviewed.  The  literature  in  the  four  main 
functional  areas:  1)  mobility,  2)  perception,  3) 
manipulators,  and  4)  IC2  was  surveyed.  Each  area,  in 
itself,  could  use  an  in  depth  literature  search  and  study  of 
approximately  six  months.  There  was  not  sufficient  time  for 
that,  although  each  area  was  reviewed  sufficiently  to 
recommend  the  most  likely  areas  to  give  the  desired  results. 
In  addition  to  reading  and  interviewing,  several  seminars  on 
robotics  were  attended  to  keep  abreast  of  current  efforts 
and  to  make  additional  contacts  within  the  field. 

Armed  with  some  knowledge  of  what  was  available  in  the 


field,  the  4950th  TW/OMS  was  visited.  The  maintenance 
personnel  were  observed  and  interviewed  to  define  general 
maintenance  duties.  The  R&D  program  addressed  these  general 
duties,  not  specifically  how  the  duties  were  done.  To  fully 
implement  this  program,  a  thorough  study  of  all  Air  Force 
aircraft  must  be  done  to  define  the  how  (with  respect  to  the 
android),  and  the  previously  mentioned  in  depth  literature 
search  and  study  must  be  done,  also.  The  program  did  not 
discuss  maintenance  of  the  android,  that  is,  whether  the 
android  would  maintain  itself  and/or  others,  or  whether 
human  maintenance  would  be  required. 

To  provide  AFIT  with  a  means  of  assisting  in  this  R&D 
effort,  a  hardware  project  was  undertaken.  This  project 
consisted  of  consolidating  past  AFIT  efforts  (both 
successful  and  unsuccessful)  at  building  a  working  mobile 
platform.  This  was  done,  and  is  ready  for  follow  on  work  as 
small  projects  and/or  thesis  efforts. 

Conclusions 

1.  When  examined  logically,  the  R&D  program  should 
provide  the  desired  results  if  appropriate  funding  and 
manpower  are  provided. 

2.  The  platform  moves  and  is  ready  to  have  various 
devices  attached  and  interfaced  to  it,  such  as  sensors, 
manipulators,  artificial  intelligence,  and  IC2  in  general. 

3.  Based  on  the  literature,  a  central  clearing  house  is 
needed  to  help  provide  coordination,  cooperation,  and 
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communication  among  the  various  disciplines  involved  in  this 
field.  This  would  help  the  various  disciplines  to  approach 
robots  and  androids  from  a  holistic  point  of  view. 

Recommendations 

1.  It  is  suggested  that  the  R&D  program  as  outlined  in 
Chapter  IV  be  supported  and  carried  through. 

2.  It  is  suggested  that  coordination,  cooperation,  and 
communication  among  the  various  disciplines  in  the  robotics 
field  be  supported  and  encouraged. 

3.  It  is  suggested  that  a  'Central  Clearing  House*  on 
robotics  be  considered  and  established.  A  description  is 
given  later. 

4.  It  is  suggested  that  robotic  efforts  in  academia, 
industry,  and  DOD  be  supported  and  encouraged  through 
meetings,  workshops,  seminars,  classes,  research,  and 
sponsorship. 

5.  It  is  suggested  that  Air  Force  personnel  be  trained 
at  various  levels  in  this  field,  to  meet  the  Air  Force's 
current  and  future  needs  as  managers,  researchers, 
technicians,  implementors,  and  maintainers. 

6.  It  is  suggested  that  AFIT,  via  the  School  of 
Engineering  and  the  Civilian  Institution  Program,  establish 
an  accepted  curiculum  in  robotics  and  its  related  fields. 

7.  It  is  suggested  that  the  AFIT  staff  and  students 
conduct  research  in  these  fields  with  Air  Force  goals  in 
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mind . 


8.  It  is  suggested  that  AFIT  teach  short  courses  and 
continuing  education  courses  to  train  Air  Force  managers  and 
other  DOD  personnel  in  the  basic  robotic  disciplines  to 
facillitate  better  management  of  robot  related  requirements. 

9.  It  is  suggested  that  the  AFIT  platform  (also  known 
as  ' R2P2 * ,  Roz '  s  Research  Platform  Project)  continue  to  be 
used  as  a  mobile  research  test  base. 

10.  It  is  suggested  that  the  computerized  maintenance 
system  currently  being  tested  be  further  evaluated  and 
possibly  expanded  to  provide  a  data  base  access  for  the 
maintenance  android. 

Further  Recommendations  for  R2P2 

1.  It  is  suggested  that  the  input  signal  controller  be 
replaced  by  a  microcomputer  and  appropriate  D/A  signal 
converter . 

2.  It  is  suggested  that  reevaluation  of  the  motors  and 
motor  controllers  if  R2P2  should  ever  weigh  more  than  100 
pounds  with  all  of  its  equipment  on  board. 

3.  It  is  suggested  that  the  sensors  and  related  IC2  be 
added  to  R2P2  in  stages: 

a.  To  what  is  now  available,  add  a  hole  sensor  to 
prevent  R2P2  from  wandering  into  open  stairwells  or  elevator 
shafts ; 

b.  Add,  to  a.,  side  sensors  and  a  forward  sensor 
to  allow  R2P2  to  detect  stationary  objects  and  respond, 
including  box  canyon  type  of  situations; 


c.  Add,  to  b.  ,  sonar  sensors  to  detect  stationary 
versus  moving  obstacles,  inclines,  and  holes  while  using  the 
sensors  in  b.  as  a  failsafe  measure: 

1)  Minimally,  using  those  sensors  found  in 
self-focusing  cameras; 

2)  Preferably,  using  one  of  the  more  advanced 
sonic  or  ultrasonic  sensing  devices; 

4.  It  is  suggested  that  the  previously  accomplished 
battery  supplied  voltage  for  the  MMD-1  be  evaluated. 

5.  It  is  suggested  that  artificial  intelligence  work 
be  designed  and  implemented  on  R2P2. 

6.  It  is  suggested  that  speech  and  speech  recognition 
be  implemented  on  R2P2  once  Dr.  Kabrisky's  laboratory  feels 
it  is  ready  to  test  mobilized  speech,  speech  recognition, 
and  response. 

7.  It  is  suggested  that  vision  and  vision  recognition 
be  implemented  on  R2P2  once  Dr.  Kabrisky's  laboratory  feels 
it  is  ready  to  test  mobilized  vision,  vision  recognition, 
and  response. 

8.  It  is  suggested  that  AFIT  evaluate  and  buy  two 
manipulators  for  use  and  testing: 

a.  One  for  bench  use  and  testing; 

b.  One  for  R2P2  (mobile)  use  and  testing. 

9.  It  is  suggested  that  AFIT  consider,  evaluate,  and 
buy  one  of  the  whole  robot  kits  currently  available,  such  as 
Heath's  HEROI . 

10.  It  is  suggested  that  the  current  microcomputer 


technology  be  evaluated  to  determine  if  a  better 
microcomputer  chip  is  available  to  be  used  in  R2P2  as  part 
of,  and  to  form,  an  overall  1C2  network.. 


Description  of  a  Robotic  Clearing  House 

There  should  be  one  government  backed  group  to  serve  as 
a  central  clearing  house  for  robotic  android  research  and 
development.  This  could  be  privately  run,  i.e.  a  foundation 
supported  by  the  government.  In  part,  this  is  contrary  to 
the  opinion  expressed  by  DOD  Deputy  undersecretary,  Edith 
Martin . 

Instead  of  a  central  administration  for  a  robotics 
program,  Martin  suggested  an  information  exchange 
system  using  data  base  technology.  A  program  to 
assess  the  impact  and  development  of  robots  across 
the  entire  spectrum  of  technology  to  take  place 
every  two  years,  is  also  under  discussion  (Military, 
1982:  4). 

However,  the  final  results  of  Martin’s  suggestion  would 
parallel  those  espoused  here. 

The  new  group  would  function  as  a  clearing  house  for  all 
government  funded  research.  It  is  needed  to  serve  as 
coordinator,  communicator,  and  cooperator.  It  would  also 
dissemenate  unclassified/classified  information  resulting 
from  the  sponsored  research.  (Of  course  classified 
information  would  only  be  passed  on  after  meeting  the  then 
current  requirements  for  receiving  classified  information.) 
This  relationship  is  illustrated  in  Figures  5  and  6. 


Figure  5.  Clearing  House  Relationships 
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INFORMATION 


information  in  this  field,  it  could  coordinate  research 
efforts  nationwide  and  provide  better  communications  among 
all  the  researchers.  With  the  increased  communication,  a 
possible  outgrowth  is  standardization  of  terms  and 
information . 

The  information  pool  would  help  minimize  the  unnecessary 
duplication  of  efforts  in  areas  already  explored,  possibly 
provide  points  for  future  research  and/or  investigation,  and 
most  importantly,  open  the  way  for  better  communication 
among  the  various  researchers  working  on  robotics.  These 
different  areas  are  so  diverse  and  many,  that  for  one  person 
to  be  expert  or  even  understand  them  all  is  nearly 
impossible.  A  group  would  have  at  least  one  expert  in  each 
area,  and  interface  people  would  be  needed  to  serve  as 
'interpreters'  among  the  different  experts  to  enhance  these 
communications . 

The  group  should  have  a  central  site,  representatives 
who  are  co-located  with  major  research  and  development 
participants  (both  academic  and  industrial),  and  Roving 
representatives  to  work  with  and  visit  those  places  which 
would  not  qualify  for  a  permanent  representative.  The  group 
could  conduct  its  own  research  as  well  (with  all  of  those 
experts  in  one  place,  working  together  on  research  seems 
reasonable).  The  education  with  industry  and  military 
research  associate  programs  would  benefit  heavily  from  this 
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Related  Sources  Bibliography  (Annotated) 


This  bibliography  contains  material  of  possible  interest  to 
those  continuing  the  research  and  work  suggested  by  this 
thesis.  This  information  and  that  contained  in  Appendix 
E  were  discovered  while  preparing  this  thesis.  The 
information  was  not  directly  pertinent  to  this  thesis 
but  could  be  valuable  to  those  whose  work  follows. 

Several  of  the  electronics  trade  type  magazines  (for 
technicians  and  repairmen)  discuss  parts,  and  components 
suitable  for  robotic/android  usage. 


Ballard,  Dana  H.  and  Christopher  M.  Brown.  Computer  Vision. 
"Explores  the  technical  and  theoretical  aspects  of 
computer-based  systems  of  vision.  From  image  scanning 
to  frame  theory,  from  programming  for  coordinates  to 
problems  of  image  definition  and  recognition,  covers 
important  topics  as  optical  flow,  templates  and  image 
geometry,  control  stategies  and  control  mechanisms  and 
more"  (Recent,  1982).  I  had  purchased  this  book,  but 
before  I  reviewed  it  thoroughly,  I  loaned  it  to  Dr. 
Kabrisky  (this  is  one  of  his  areas).  Unfortunately,  at 
this  time,  he  still  has  the  book  so  I  am  unable  to 
provide  the  full  bibliographic  information.  The 
copywrite  date  should  be  1982  or  1981. 

Barr,  Avron,  Paul  R.  Cohn,  and  Edward  A.  Feigenbaum. 
Handbook  of  Artificial  Intelligence,  Volumes  I  and  II . 
RE:  Vol  I,  "Outstanding  collection  of  articles  on  AI 

research,  produced  at  Stanford  University.  How 
computers  exhibit  near-human  intelligence"  (Recent, 
1982).  RE:  Vol  II,  "This  comprehensive  collection  of 
papers  and  articles  inquires  into  areas  like  programming 
languages  for  AI  research ...  data  structures  and  control 
structures  for  the  AI  environment. . .AI  research  for 
scientific  appl icat ion ...  database  storage  and  retrieval 
techniques  for  the  AI  environment ...  and  more"  (Recent, 
1982)  . 

Bejczy,  A.  K.  Advanced  Robot  Control:  A  Tutorial  Workshop. 
Bejczy  was  the  organizer  of  this  workshop  at  the  20th 
IEEE  Conference  on  Decision  and  Control,  held  in  San 
Diego,  CA  on  16-18  December  1981.  The  three  sessions 
were  1)  Robot  mechanisms,  sensors  and  control,  2)  The 
mathematics  of  robot  control,  and  3)  visual  sensing  for 
robot  conntrol.  The  flyer  summarized  the  workshop  as 
follows : 

The  development  of  advanced  robots  calls  for  the 
study  and  implementation  of  advanced  feedback  control 
systems.  This  tutorial  workshop  (i)  will  provide  an 


introduction  to  robot  control  problems  and  to  robotics 
in  general,  and  (ii)  will  outline  the  technical  meaning 
of  "advanced  feedback  control"  within  the  context  of 
advanced  robot  control.  Robot  modeling  for  control,  the 
mathematics  of  robot  control  and  sensor-referenced  robot 
control  systems/tehcniques  will  be  discussed. 

If  this  was  published  as  other  IEEE  tutorials  have 
been,  this  would  probably  be  worthwhile  to  have  in  the 
library  and  for  those  working  in  the  areas  discussed. 

Chang,  S.  K.  The  Translation  of  Fuzzy  Queries.  This  was  a 
paper  scheduled  to  be  given  at  the  1980  IEEE  COMPSAC, 
but  was  not  included  in  the  proceedings  for  the  1980 
COMPSAC.  Only  the  abstract  was  included,  and  described 
the  paper  as  dealing  with  the  translation  of  fuzzy,  or 
imprecise,  queries  for  a  relational  data  base  system. 
Examples  were  to  be  presented  for  fuzz  translation,  and 
extension  to  pictorial  fuzzy  query  translation  was  also 
to  be  discussed.  Knowledge  Systems  Laboratory, 
University  of  Illinois  at  Chicago,  Chicago,  Illinois  was 
the  affiliation  given  for  the  author.  This  paper  might 
be  worthwhile  to  someone  working  with  fuzzy  set  theory 
and  the  android's  decision  making  capabilities. 

Electronic  Products .  Special  Reference  Issue  on  "Controls, 
Drives,  and  Switches".  Volume  24  Number  8,  30  November 
1981.  Some  article  titles  include  "The 

Encoder/Controller  Interface",  "I/O  Modules  Refine 
Industrial  Control",  "Source  List:  Motors",  "Don't 
Confuse  Pressure  Sensors  and  Transducers",  "Source  List: 
Pressure  Transducers",  and  "Source  List:  Temperature 
Transducers" . 

Freedman,  M.  David,  and  Lansing  B.  Evans.  DESIGNING  SYSTEMS 
WITH  MICROCOMPUTERS :  a  systematic  approach.  This  is  a 
forthcoming  book  from  Prentice-Hall:  1983.  Excerpts 
from  this  book  were  used  as  course  notes  for  a  seminar 
sponsored  by  the  Engineering  Society  ol  Detroit, 
Detroit,  Michigan,  20-21  September  1982.  Dr.  Freedman 
has  developed  an  English  programming  design  language 
( not  just  a  'pseudo-English'  design  language).  He  also 
has  a  translator  which  takes  his  design  language  (85%) 
to  PL/M.  He  either  has  or  plans  to  extend  this  to  an 
additional  HOL  such  as  FORTRAN  or  PASCAL.  His  design 
language  is  presented  in  his  book.  This  design  language 
is  much  easier  for  the  customer  to  understand,  and 
minimizes  the  programmer's  natural  tendancy  to  jump  into 
coding.  The  machine  translation  of  the  design  language 
to  code,  provides  a  more  standard  approach  to  coding 
which  makes  maintenance  a  little  easier  since  the  code 
for  most  of  the  routines  is  consistent. 

Geschke,  Clifford  Calvin.  A  System  for  Programming  and 
Controlling  Sensor-Based  Robot  Manipulators.  The  thesis 
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was  submitted  in  partial  fulfillment  of  the  requirements 
for  the  degree  of  Doctor  of  Philosophy  in  Electrical 
Engineering  in  the  Graduate  College  of  the  University  of 
Illinois  at  Urbana-Champaign ,  1979.  DTIC  #AD  a077224. 
The  thesis  advisor  was  Professor  R.  T.  Chien.  The 
literature  reveiwed  and  remarked  upon  is  pre-1978.  This 
is  primarily  a  feedback  control  thesis,  research  and 
bibliography.  Even  though  it  is  not  what  I  had  in  mind 
for  android  implementation,  it  could  provide  good 
background  and  thought  stimulus  for  people  doing  future 
work  on  feedback  control  for  the  android.  If  it  is  not 
too  far  into  the  future  when  the  feedback  control  work 
is  done,  this  thesis  should  be  worth  several  hours  of 
reading  and  thought.  When  the  Conference  was 
advertised,  the  person  to  contact  was: 

Professor  D.  Pierre,  Chairman 

IEEE  CSS  Education  Committee 

Department  of  Electrical  Engineering  and  Computer 
Science, 

Montana  State  University, 

Bozeman,  Montana  59717 

Hobby  Robot  Co.  Robots  and  modules  for  sale.  They  have  a 
catalog  with  complete  robots  and  robot  parts.  See 
appendix  E  for  address. 

IEEE.  Computer ,  15  (12):  December  1982.  The  whole  issue 
discusses  robotic  topics.  "In  this  issue:  Robotics  & 
Automation,  1982  Annual  Index" — quoted  from  cover  of 
magazine. 

"INFOWORLD:  The  Newsweekly  for  Microcomputer  Users."  Toll 

free  subscription  line:  800-343-6474  (Massachusetts 
617-879-0700).  Is  available  on  35mm  microfilm  through 
University  Microfilm,  Periodical  Entry  Dept,  300  North 
Zeeb  Road,  Ann  Arbor,  MI  48106  (313)  761-4700. 

According  to  the  8  November  1982  issue,  "in  upcoming 
issues  of  InfoWorld,  you  will  find  coverage  of 
developments  in  the  field  of  industrial  robotics.  We 
will  look  at  the  kinds  of  jobs  that  robots  are  doing 
right  now,  the  size  and  nature  of  the  factory-robotics 
market,  the  burgeoning  Japanese  robotics  industry  and 
the  social  costs  and  benefits  of  factory  automation. 
The  steel-collar  revolution  in  factory  automation  is  not 
all  there  is  to  robotics.  We  will  also  monitor  garage 
laboratories  where  hobbyists,  in  a  rough  parallel  with 
the  early  days  of  the  personal-computer  industry,  are 
breaking  new  ground  in  what  could  be  a  personal  robotics 
industry.  We  will  examine  their  homebrew  systems  while 
keeping  you  current  with  the  state  of  the  art  in  robot 
vision,  locomotion  and  manipulation.  In  this  issue,  to 
kick  off  our  coverage  •f  robotics,  we  focus  on  the 
emerging  hobby-robotics  movement."  Hobby  robotics 
movement  is  covered  on  pages  25-29  of  8  November  1982 
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issue.  The  29  November  1982  issue  has  a  follow-on 
article  on  hobby  robotics  ( RB5X )  on  page  16. 

Jain,  Ramesh  and  Susan  Haynes.  "Imprecision  in  Computer 
Vision",  Computer,  15  (8):  39-48  (August  1982).  IEEE 

number  is  0018-9162/82/0800-0039$00. 75 .  One  of  four 
articles  on  fuzzy  set  theory  provided  by  Lt  Jerry 
Montgomery  as  part  of  his  lecture  on  fuzzy  set  theory 
and  his  thesis.  It  discusses  fuzzy  set  theory  and  its 
application  to  computer  vision.  It  has  28  references, 
some  on  fuzzy  set  theory  and  others  related  to  the 
application . 

Jarvis,  R.  A.  "A  Computer  Vision  and  Robotics  Laboratory", 
Computer,  15  (6):  8-24  (June  1982).  The  author  is  a 

reader  in  computer  science  at  the  Australian  National 
University,  Canberra.  He  has  a  PhD  in  electrical 

engineering  and  his  current  research  interests  include 
digital  computing  technology,  pattern  recognition , image 
processing,  computer  vision,  and  robotics.  This  article 
has  34  references.  The  IEEE  number  is 

0018-9126/82/0600-0008$00. 75. 

Kent,  Ernest  W.  The  Brains  of  Men  and  Machines . 
BYTE/McGraw  Hill,  Peterborough,  N.  H. :  1981.  This  book 

talks  about  the  human  brain,  its  organization,  its 
structure  and  functional  characteristics  and  how  they 
could  be  applied  to  the  development  of  intelligent 
robotic  systems.  The  bibliography  is  by  subject  and  has 
some  annotations.  Good  starting  place  for  those 
interested  in  android  control  systems,  those  working  on 
the  hardware,  and  those  working  on  the  software. 
Interesting  point  of  view,  and  starts  with  the  basic 
principles  and  works  up  from  there. 

Malvania,  Nikhil.  The  Design  of  a  Modular  Laboratory 
for  Control  Robotics.  Thesis  for  MS  degree  at 
Massachusetts  Institute  of  Technology,  September  1976. 
MIT/LCS/TM-74.  Supported  by  the  Advanced  Research 
Projects  Agency  of  the  Department  of  Defense  and 
monitored  by  the  Office  of  Naval  Research  under  contract 
no.  N00014-75-C-0661.  DTIC  #  AD-A030418.  Although  this 
is  old,  too,  it  starts  out  with  classical,  digital,  and 
computer  control  introduction.  It  discusses  the 
Daemonized  approach  to  computer  control,  and  controlling 
power  of  a  processor.  It  was  not  what  I  had  hoped  it 
would  be  when  I  requested  the  copy  of  the  document.  At 
the  time  of  the  thesis'  publication,  the  laboratory  had 
not  been  implemented  and  was  not  expected  to  be 
implemented . 

Naedel,  R.  G.  "Intelligent  Associative  Memory  (IAM) 
Architecture".  A  report  of  work  done  by  Intellimac, 
Inc.  6001  Montrose  Road,  Rockville,  MD  20852.  The  work 
was  done  under  U.S.  Government  contract,  so  a  copy  of 
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the  report  should  be  available,  somewhere.  For  those 
working  on  associate  memories,  this  may  be  helpful,  Lt 
Montgomery  did  not  think  so.  But,  it  may  have  been  that 
it  was  not  what  he  was  looking  for. 

Nevatia,  Ramakant.  Machine  Perception.  Englewood  Cliffs, 
New  Jersey,  Prentice-Hall,  Inc.:  1982.  "Detailed 
exploration  of  the  problems  encountered  and  the 
techniques  employed  to  develop  machines  that  can  'see' 
the  world  around  them.  The  book  covers  everything  from 
a  brief  discussion  of  pattern  classification  methods  to 
three-dimensional  scenes,  from  the  relationship  of 
veiwing  angle  to  perspective,  to  complex  segmented 
models"  (Recent,  1982).  This  book  has  at  least  two 
pages  of  references  for  most  chapters.  The  chapter 
titles  are  "Introduction,  Pattern  Classification 
Methods;  Simple  Polyhedral  Scenes;  Complex  Scenes  of 
Polyhedra;  Shape  Analysis  and  Recognition;  Perception  of 
Brightness  and  Color;  Edge  and  Curve  Detection;  Region 
Segmentation  and  Texture  Analysis;  Depth  Measurement 
Analysis;  Knowledge  Based  Systems  and  Applications." 

Proceedings  of  the  Fifth  International  Symposium  on 
Industrial  Robots .  IIT  Research  Institute,  Chicago, 
Illinois,  September  22-24,  1975.  Sponsored  by  the 

Society  of  Manufacturing  Engineers,  IIT  Research 
Institute,  and  the  Robot  Institute  of  America;  others 
involved  were  The  Charles  Stark  Draper  Laboratory,  Inc.  , 
Stanford  Reserach  Institute  (Aritificial  Intelligence 
Center),  National  Bureau  of  Standards,  and  the  Office  of 
Developmental  Automation  and  Control  Technology. 
Published  by  the  Society  of  Manufacturing  Engineers, 
Dearborn,  Michigan,  1975.  (Received  on  Inter-Library 
Loan  from  Clemson  University. )  The  various  papers  deal 
with  industrial  robots  primarily,  however,  the 
information  on  vision,  manipulators,  "computer-aided 
robot  operation  systems  design",  control  (algorithmic 
and  adaptive),  and  so  on.  Information  which  is 
applicable  to  industrial  robots  may  be  adaptable  for  use 
with  an  android. 

Proceedings  of  the  International  Joint  Conference  on  Pattern 
Recognition.  Mentioned  in  the  1982  Publications  Catalog 
of  the  IEEE  Computer  Society  Press,  pg  24.  "With  the 
growing  interest  in  robotics  and  manmade  interaction, 
the  discipline  of  pattern  recognition  is  coming  into  its 
own."  The  fifth  conference  was  held  in  December  1980 
and  has  two  volumes.  The  descriptive  quote  from  the 
catalog  implies  the  fifth  and/or  future  proceedings  of 
this  conference  would  bear  watching  for  papers  of 
possible  interest  to  roboticists. 

Proceedings  of  the  Joint  Automatic  Control  Conference 
( JACC ) ,  1981.  In  Robotics  Age,  I  found  a  reference  to 
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“Control  of  a  Robotic  Exercise  Machine"  by  Wayne  Book 
and  David  Ruise.  Unf orturnately ,  the  article  and/or 
proceedings  could  not  be  found.  If  the  conference  were 
held  late  in  the  year,  publication  of  the  proceedings 
does  take  quite  a  while. 

Proceedings  of  the  Pattern  Recognition  and  Image  Processing. 
"At  this  conference  practitioners  discuss  approaches  to 
flexible  and  intelligent  human  interface  to  pattern  and 
pictorial  data.  Topics  have  included  user-oriented 
graphics,  industrial  applications,  remote  sensing  and 
image  processing,  speech  understanding  and  sound 
analysis,  and  data  definition  and  conversion." 

Mentioned  in  the  1982  Publications  Catalog  of  the  IEEE 
Computer  Society  Press,  pg  25.  Titles  read  "19XX 
Conference  on  Pattern  Recognition  and  Image  Processing". 
Apparently  the  conference  is  held  every  two  years. 

Proceedings  of  the  Sixth  International  Joint  Conference  on 
Artif ical  Intelligence ,  Tokyo ,  August  20-23 ,  1979 , 

Volumes  I  and  II .  (A.K.A.  IJCAI-79)  Has  several  papers 

directly  written  on  and  related  to  robotics.  The  areas 
include  image  anaylsis,  robotics,  vision,  object 
detection,  and  problem  solving. 

Proceedings  of  the  Third  Symposium  on  Theory  and  Practice  of 
Robots  and  Manipulators,  Udine,  Italy,  1978.  Good  for 
seeing  what  is  being  done  in  robotics,  internationally. 
Nearly  six  hundred  pages  of  papers  presented.  Published 
in  1980  by  Elsevier  Scientific  Publishing  Company, 
Amsterdam  -  Oxford  -  New  York;  and  Polish  Scientific 
Publishers,  Warszawa. 

Robotics  Age:  The  Journal  of  Intelligent  Machines . 
Interesting  magazine,  geared  primarily  for  the  hobbist. 
The  articles  range  from  image  processing,  artificial 
intelligence,  to  how  to  build  your  own  "backyard"  robot. 
The  advertisements  are  interesting  and  could  provide 
leads  to  track  down  parts  or  supplies  of  interest  as 
well  as  books  on  the  subject.  Regular  features  include 
"New  Products",  "Media  Sensors",  "Organizations",  and 
"Books " . 

Robotron  4201  Minicomputer  System  Summary.  This  is  an  old 
document  but  is  a  translation  of  work  done  in  East 
Germany.  The  DTIC  copy  I  received  is  an  "edited 
Translation"  with  FTD-ID{RS )T-1269-77  dated  29  November 
1977.  The  DTIC  # ADB  025595L.  "The  present  system 
summary  corresponds  to  the  status  as  of  November  1975. 
The  right  to  make  changes  resulting  from  further 
technical  development  is  reserved.  Reprinting, 
reproduction  of  these  documents  and  excerpts  therefrom 
are  unauthorized".  I  remember  seeing  several  articles 
on  Robotron  4201  when  I  was  doing  my  literature  search, 
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mostly  untranslated  except  for  the  abstract  and 
reference  I  was  reading.  Although  this  is  out  of  date, 
it  would  answer  some  questions  about  the  work  being  done 
in  East  Germany,  as  well  as  raising  other  questions. 

Safford,  Edward  L. ,  Jr.  The  Complete  Handbook  of  Robotics. 
Tab  Books,  Blue  Ridge  Summit4,  PA:  T978.  This  Is 
geared  more  for  the  robot  hobbyist,  but  helps  to  get  the 
mind  moving  and  thinking,  even  when  you  disagree  with 
what  is  said  and  done.  It  is  fairly  easy  to  read  and 
hits  most  every  area  of  interest  to  a  roboticist  or 
androidist.  It  is  worth  looking  at  in  pieces  for  an 
overview,  almost  lay-type  of  view,  of  the  area  of 


interest, 
control , 

such 

etc. 

as 

sensors , 

servomechanisms,  radio 

Sembi,  B.S. 

and  E. 

H. 

Mamdani . 

Linguistic  Rule-Based 

Decision 

Making 

Using 

Fuzzy 

Logic.  This  was  to  be  a 

paper  presented  at  the  1980  IEEE  COMPSAC.  All  that 
appeared  in  the  proceedings  was  the  abstract.  The 
abstract  states  that  the  decision  making  in  this  case 
was  to  be  applied  to  process  control  systems  but  using  a 
general  technique.  For  those  contemplating  fuzzy  logic 
for  decision  making  in  the  android,  this  paper  might  be 
worth  running  down. 

Spegel,  Marjan.  Programming  of  Mechanism  Motion.  Technical 
Report  CRL-43,  November  1975.  A  thesis  prepared  for 
Information  Systems  Program,  Office  of  Naval  Research, 
Department  of  the  Navy.  Contract  No.  N00014-75-C-0572 , 
NR  049-274. w  DTIC  #  AD-A023  171.  Again,  this  is  an 
older  publication.  It  provides  a  motion  description  in 
1-D,  uses  FORTRAN  as  its  HOL,  but  the  motion  description 
could  be  expanded  by  hand  to  any  other  HOL.  If  a 
special  language  were  needed  to  be  developed  for  the 
android's  motion  programming,  looking  at  what  Spegel  did 
here  would  be  good  to  see  what  one  approach  was.  The 
developer  could  use  this  as  a  basis  for  deciding  how  he 
or  she  would  develop  the  android's  motion  descriptive 
language.  Some  times  it  is  easier  to  look  at  someone 
else's  approach  and  say  no,  that  was  the  wrong  approach 
there,  I  think  this  is  a  better  way;  than  to  come  up 
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APPENDICES 


Appendix  A 


Analysis  Diagrams 


The  following  ten  diagrams  organize  the  data  presented 
in  chapter  II.  Each  diagram  is  followed  by  descriptive 
text.  The  Data  Dictionary  which  describes  the  terms  used  in 
the  diagrams,  is  included  in  Appendix  B.  The  ten  diagrams 
are  numbered  and  titled  in  accordance  with  standard  SADT 
practices.  I.e.,  the  first  diagram  is  "A-0",  the  next 
diagram  in  sequence  is  "AO",  the  third  diagram  is  labeled 


Figure  7.  A-0,  Maintain  Aircraft 


A-0,  Maintain  Aircraft 

This  is  the  simplest  view  of  the  aircraft  maintenance 
system.  The  activity  box  representing  "make  aircraft 
flyable"  is  simply  what  aircraft  maintenance  does.  The 
inputs  needed  are  the  actual  aircraft,  those  items  which  are 
consumable  (and  always  needed  for  every  aircraft  for  every 
mission),  those  spares  needed  to  repair  or  replace  items  on 
the  aircraft  which  are  within  maintenance's  realm  of 
responsibility,  and  those  resources  which  are 
mission-particular  (i.e.  mission  dependent).  The  outputs 
are  the  required  maintenance  histories,  maintenance  reports, 
and  the  aircraft  status.  All  three  of  these  may  be  oral, 
written,  or  both.  As  indicated  by  the  diagram,  the 
technical  orders  (TOs)  and  the  current  status  of  the 
aircraft  control  the  aircraft  maintenance  procedure. 
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It  is  not  unusual  for  flight  crew  members  to  talk  to 
maintenance  personnel  about  the  aircraft  assigned  for  a 
particular  mission.  This  exchange  allows  maintenance  to 
request  that  the  crew  member (s)  make  specific  observations 
under  specified  conditions.  This  could  help  maintenance 
pinpoint  an  elusive  malfunction.  This  exchange  also  enables 
the  flight  crew  to  be  forewarned  of  possible  equipment 
failure  or  malfunction.  For  example,  if  for  the  last  six 
months  every  flight  shows  a  particular  failure  occurring 
during  flight,  the  crew  might  reasonably  expect  that  failure 
to  recur.  This  is  especially  true,  if  the  same  repair 
technique  is  noted  in  the  maintenance  history  for  that 
component ! 

Alternately,  if  a  piece  of  equipment  (such  as  one  of  the 
navigation  aids)  has  run  perfectly  for  six  or  more  months, 
the  navigator  frequently  refreshes  his  memory  on  how  to  do 
that  particular  navigation  aid’s  work  manually.  Similarly, 
other  interested  personnel,  on  a  need  to  know  basis,  request 
written  and/or  oral  reports  on  particular  aircraft.  These 
reports  enable  scheduling  to  schedule  particular  aircraft 
for  particular  missions. 

When  USAF  personnel  describe  the  Air  Force's  mission  as 
'To  Fly  and  Fight',  the  status  of  an  aircraft  becomes  very 
important  and  of  interest  to  many  individuals.  When  an 
aircraft  is  ready  to  fly  (according  to  maintenance 
standards),  the  aircraft  status  reflects  that,  and  the 
aircraft  is  held  in  its  appropriate  area  or  hangar. 


AO,  Make  aircraft  Flyable. 

The  three  aircraft  maintenance  phases  are  post-flight 
check,  ground  maintenance,  and  pre-flight  check.  But, 
before  maintenance  personnel  can  do  these.,  the  specific 
aircraft  has  to  be  identified  as  well  as  its  mission.  These 
two  identifications  and  the  aircraft  itself  are  necessary  to 
begin  the  aircraft  maintenance  procedure.  Preparation  for 
maintenance  can  begin  prior  to  the  actual  arrival  of  the 
aircraft,  once  identification  is  complete. 

Each  phase  of  maintenance  generates  its  own  histories, 
reports,  and  aircraft  status.  The  aircraft  status 
determines  what  maintenance  is  done  and  when.  Some  of  the 
maintenance  procedures  of  one  phase  can  overlap  those  of 
another  phase,  assuming  all  necessary  controls  and  inputs 
are  available. 
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Figure  9.  A2,  Identify  Aircraft 


A2,  Identify  Aircraft. 

The  aircraft  identification  is  constructed  from  two 
pieces  of  information.  This  information  comes  directly  from 
the  aircraft  itself.  The  first  piece  is  the  aircraft  typ*' 
such  as  B-52  bomber  or  F-4  fighter.  The  second  piece  is  the 
specific  aircraft  identity  denoted  by  the  tail  number. 
These  two  pieces  of  information  form  the  specific  aircraft 
identification  for  maintenance  purposes. 
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Figure  10.  A3,  Accomplish  Post-Flight  Check 


A3 ,  Accomplish  Post-Flight  Check. 

The  post-flight  check  consists  of  directing  the  aircraft, 
securing  the  aircraft,  decontamination  of  the  aircraft  (if 
necessary),  and  physically  inspecting  the  aircraft.  Part  of 
securing  the  aircraft  can  be  accomplished  prior  to  the 
aircraft's  arrival.  Once  the  aircraft  is  parked,  it  is  made 
secure  and  safe,  so  that  the  ground  maintenance  personnel 
can  work.  Then,  decontamination  starts  and  the  physical 
inspection  continues  since  the  inspection  starts  while  the 
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aircraft  is  being  secured.  (I.e.  as  the  maintenance 
personnel  work  on  or  around  the  aircraft  they  contninually 
watch  for  physical  damage  or  anything  out  of  the  ordinary. ) 

Once  the  aircraft  is  safe,  physical  inspection  continues 
and/or  decontamination  begins.  Physical  inspection  of  an 
aircraft  includes  examining  all  surfaces  for  damage,  loose 
screws  and  bolts,  checking  engines  and  blades  (internal  and 
external)  for  damage  and  foreign  debris,  checking  gauges, 
ensuring  landing  gear  and  flight  controls  are  within 
tolerances,  and  checking  cables  for  tension  and  damage. 

Decontamination  is  generally  accomplished  by  hand,  by 
personnel  in  the  appropriate  protective  gear.  The  aircraft 
is  literally  scrubbed  down  with  burshes,  soap  and  water,  or 
whatever  is  required  to  remove  the  contaminants.  The 
general  consensus  is  that  these  protective  suits  are 
cumbersome,  awkward,  and  dangerous  in  their  own  right. 
However,  they  are  better  than  nothing!  Even  though  this  is 
a  robot/android  scenario,  decontamination  is  necessary  if 
the  crew  is  to  deplane,  if  the  contaminate  would  damage  the 
aircraft,  or  if  people  must  do  the  repairs  on  the  aircraft. 

Once  the  aircraft  is  safe  for  the  ground  maintenance 
crew  to  start  work,  and  the  aircraft  status  indicates  the 
need,  the  ground  maintenance  work  begins. 


A/C-STATUS  A/C -MISSION 


Figure  11.  A31,  Direct  Aircraft 


A31,  Direct  Aircraft.  If  an  aircraft's  crew  were 
unfamiliar  with  an  airfield,  the  aircraft  would  be  directed 
from  its  landing  point  to  the  appropirate  taxiway,  and 
parking  aprons.  The  follow-me  or  park-on-me  normally  uses  a 
vehicle  with  lights  and  the  appropriate  label  to  lead  the 
aircraft.  All  aircraft  are  directed  into  their  final 
parking  place  since  obstacles  are  usually  nearby  which  can 
damage  the  aircraft  or  be  damaged  by  the  aircraft.  This  is 
called  marshalling.  Marshalling  is  accomplished  by  one  or 
more  individuals  with  hand-held  signal  lights  used  to  guide 
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the  aircraft  into  its  final  parking  place.  This  requires 
the  status  of  the  aircraft  with  respect  to  its  current 
location  and  its  desired  location.  The  final  parking  place 
is  reached  by  following  the  arm  signals  of  one  or  more 
ground  maintenace  crew  members  who  compare  the  distance 
between  the  aircraft,  any  nearby  objects,  and  the  aircraft's 
final  desired  position. 

Thus  blocks  1  and  2  of  A31  would  not  be  required  for 
every  aircraft.  The  mission  of  the  aircraft  could  have  a 
bearing  on  where  an  aircraft  is  serviced.  For  example,  if 
both  a  test  wing  and  a  SAC  unit  are  co-located  on  the  same 
base,  each  would  generally  have  its  own  maintenance 
facilities. 


Figure  12.  A32,  Secure  Aircraft 


A32,  Secure  Aircraft.  Before  an  aircraft  is  parked  in 


its  final  maintenance  parking  place,  the  parking  area  must 


have  a  security  check. 

Once 

the  parking 

place 

meets 

the 

security  requirements 

,  the 

aircraft  could  be 

parked , 

the 

final  security  check 

is  made,  and  the 

safety 

check 

is 

initiated.  The  initial  security  check  can  begin  while  the 
aircraft  is  still  in  the  air;  it  must  be  completed  before 


the  aircraft  can  be  parked.  The  final  security  check  can 
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not  be  finished  until  the  aircraft  is  parked. 

Flight  lines  are  always  restricted  areas,  both  for 
safety  and  for  security  reasons.  In  wartime,  security  would 
be  even  more  imperative  since  resources  would  be  dwindling 
and  must  be  preserved.  Maintenance  personnel  are  expected 
to  challenge  unauthorized  personnel  (those  without  the 
proper  badges)  when  encountered  on  the  flight  line  at  any 
time.  This  involves  communication  with  people,  and 
manipulation  of  objects,  or  equipment.  When  necessary, 
maintenance  personnel  notify  the  security  police  or  area 
guards  of  unusual  circumstances  or  request  assistance. 

Once  the  aircraft  is  secure,  the  maintenance  crew  begins 
the  safety  check.  Certain  safety  precautions  must  be  done 
before  others.  Safety  pins  are  re-installed  in  munitions 
and  external  fuel  tanks  (which  have  not  been  dropped)  as 
soon  as  the  plane  lands,  prior  to  entering  the  apron/parking 
areas.  Once  parked,  safety  pins  are  re-installed  in  the 
landing  gear  to  prevent  the  gear  from  collapsing;  and  chocks 
are  placed  around  the  wheels.  Additional  safety  pins  are 
installed  for  the  canopies  and  ejection  seats  (as  needed). 
Other  safety  precautions  may  need  to  be  taken,  depending 
upon  the  aircraft  and  its  condition  (such  as  fuel  leaks  or 
hot  brakes),  and  whether  or  not  the  crew  or  munitions  are 
still  on  board.  Since  the  physical  inspection  begins  during 
the  safety  check,  one  result  is  a  report  of  discrepancies  or 
possible  damage  for  further  investigation.  Part  of  the 
safety  check  determines  whether  or  not  the  aicraft  requires 
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decontamination  at  this  time.  The  aircraft  status  reflects 
this  requirement. 


gur©  13.  A4,  Accomplish  Ground  Maintenance 


A 


A4,  Accomplish  Ground  Maintenance. 

Ground  maintenance  identifies  any  component  which  needs 
repair  or  replacement  (including  consumables/  as  required). 
A  component  is  an  item  or  subpart  of  an  item  which 
constitutes  part  of  the  aircraft,  such  as  flight  controls, 
hydraulics,  landing  gear,  engines,  black  boxes,  or  air 
frames.  To  accomplish  this,  ground  maintenance  personnel 
debrief  the  flight  crew  members  for  their  comments  on  the 
aircraft  and  its  equipment.  This  debriefing  frequently 
occurs  while  the  post-flight  check  is  conducted.  Sometimes, 
if  a  problem  is  elusive,  the  maintenance  crew  requests  the 
flight  crew  make  special  observations  during  the  next 
flight.  These  observations  are  then  given  to  maintenance 
during  the  debriefing.  In  addition  to  the  flight  crew's 
comments,  the  TOs  define  maintenance  checklists  for  each 
aircraft  and  its  components.  Once  the  maintenance  crew 
receives  the  above  information  and  has  the  aircraft 
available,  each  component  is  located  and  checked  to  see  if 
it  meets  specifications.  This  determines  the  condition  of 
the  component.  Then,  as  required,  the  components  not 
meeting  specifications  are  replaced  or  repaired.  Before 
certifying  the  component  fixed,  it  is  rechecked  to  ensure  it 
meets  specifications.  If  the  repaired/replaced  component 
meets  specifications,  then  the  next  component  is  checked  and 
the  cycle  is  repeated.  If  the  fixed  component  does  not  meet 
specifications,  then  it  is  rediagnosed  to  determine  the 
problem  and  the  requirements  to  fix  it.  This  procedure 


generates  both  maintenance  reports  and  histories.  Informal 
reports  are  updated  "continuously",  while  the  written 
reports  and  histories  are  accomplished  later.  The  status  of 
the  aircraft  is  dependent  upon  the  status  of  its  components. 
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Figure  14.  A44,  Determine  Component  Condition 


A44f  Determine  Component  Condition.  The  current 
condition  of  the  component  must  be  compared  to  the  TO's 
specifications.  If  the  aircraft  component  matches  the  TO 
specification  (within  the  acceptable  variance),  then  the 
component  is  'good'.  If  the  component  meets  the  TO 
specifications,  but  containes  consumables  which  require 
replenishing,  then  the  consumables  are  replenished.  If  the 
component  does  not  meet  the  TO  specifications,  then  it  is 
'bad'  and  must  be  repaired  or  replaced.  If  the  mission  of 
the  aircraft  requires  additional  equipment  or  supplies  from 
maintenance  which  are  not  usually  needed  but  are  needed  for 
this  particular  mission,  these  would  be  supplied  now.  This 
thesis  defined  These  as  mission  particular  resources. 


Figure  15.  A45,  Fix  Bad  Component 


A45 ,  Fix  Bad  Component.  Fixing  a  bad  component  consists 
of  either  replacing  or  repairing  it.  Once  a  component  is 
labeled  as  'bad',  the  cause  has  to  be  diagnosed  in  order  to 
fix  the  component.  Whether  the  component  can  be  repaired 
on-site ,  or  must  be  replaced  is  determined.  Then,  once  the 
component  is  thought  to  be  fixed,  it  again  has  to  be  checked 
against  the  TO  specifications.  A  replacement  could  be 
faulty,  or  the  cause  of  the  bad  component  might  be  due  to 
compound  causes.  If  the  fixed  component  meets  the  TO 
specifications,  then  the  next  component  is  checked.  If  that 
is  the  last  component  to  be  checked,  then  the  reports  and 
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status  are  updated  as  required. 

Repairs  are  done  as  necessary.  While  some  repairs  may 
be  temporarily  postponed,  such  as  a  small  brake  fluid  leak 
(found  during  a  pre-flight  check);  others  must  be  made 
immediately,  such  as  fuel  leaks  (anytime),  or  hot  brakes 
(normally  occur  during  post-flight  check).  The  danger  of  a 
fuel  leak  should  be  obvious  to  everyone — an  explosion  and/or 
fire.  Hot  brakes  can  be  just  as  dangerous  because  of 
explosion  and  possible  fire  as  well. 

Many  repairs  are  modular,  that  is,  a  malfunctioning  box 
of  equipment  can  be  pulled  out  (also  called  'unplugged')  of 
the  aircraft  and  be  replaced  with  one  functioning  properly. 
This  is  referred  to  as  'black  box'  maintenance  by  the 
maintenance  personnel.  Some  are  not,  such  as  repairing  a 
flat  tire.  A  flat  tire  must  be  repaired  because  an  aircraft 
cannot  safely  take  off  with  a  flat  tire.  An  aircraft  can  be 
landed  safely  with  a  flat  tire,  however.  Maintenance 
personnel  know  (via  TOs,  training,  and  experience)  the 
location  of  the  components  to  be  checked  and  how  often  to 
check  them  for  damage. 

Once  ground  maintenance  clears  an  aircraft  as  ready  to 
fly,  the  next  stage  before  an  actual  flight  is  the 
pre-flight  check.  This  can  occur  right  after  ground 
maintenance  was  done,  or  may  be  days  later.  The  pre-flight 
check  is  accomplished  just  prior  to  the  aircraft's  flight. 
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Figure  16.  A5,  Pre-Flight  Check 
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The  refuel  and  rearm  sequence  must  be  determined  for 
each  aircraft,  and  the  aircraft  must  be  physically 
inspected,  external  power  applied  to  the  aircraft,  and  the 
aircraft  must  be  made  safe  for  flight.  These  are  the  major 
duties  accomplished  during  the  pre-flight  check.  The 
physical  inspection,  the  external  power  hookup,  and  parts  of 
the  pre-flight  safety  check  can  be  accomplished  before, 
during,  or  after  refueling  or  rearming  and  in  any  convenient 
sequence. 

Prior  to  take-off,  a  portable  power  plant  is  hooked  up 
to  the  aircraft.  This  supplies  electric  power  for  the 
aircraft  until  the  engines  are  running.  An  'air  pusher'  may 
be  required  to  be  hooked  up  to  some  fighter  engines  as  well 
as  the  electric  power.  Once  the  engines  are  started  and 
running  under  their  own  power,  the  power  plant  is 
disconnected.  At  least  one  cable  runs  from  the  power  plant 
to  the  aircraft.  The  attachment  point  on  the  aircraft  is 
similar  in  appearance  to  a  power  outlet/wall  socket.  The 
'air  pusher'  has  a  large  flexible  tube  which  attaches  to  the 


engine,  so 

that  air  can 

be  forced 

into 

the 

engine. 

Maintenance 

personnel  know 

what  the 

power 

and 

engine 

starting  requirements  are  for  an  aircraft.  Then,  using  the 
proper  power  plant,  the  power  cables  are  plugged  into  the 
correct  recepticles,  and  the  proper  engine  starter 
mechanisms  are  attached. 

The  physical  inspection  is  the  same  as  during  the 
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post-flight  check  as  discussed  in  A3.  If  damage  is  found  or 
suspected  which  can  not  be  remedied  immediately,  the 
aircraft  returns  to  the  "ground  maintenance  required" 
status.  The  air  safety  check  is  just  the  reverse  of  the 
ground  safety  check.  Primarily,  the  landing  gear  pins, 
engine  covers,  and  chocks  must  be  removed.  The  canopy  and 
ejection  seat  pins  must  be  removed.  The  munitions  pins  and 
fuel  tank  pins  are  removed,  as  well,  but  not  until  just 
before  the  plane  takes  off  (to  prevent  any  accidents  on  the 
landing  apron  or  parking  area).  Thus,  the  maintenance 
personnel  ensure  the  aircraft  is  ready  (and  safe  for  flight) 
by  removing  the  ground-required  safeguards.  Once  the 
maintenance  crew  signals  the  flight  crew  that  maintenance  is 
complete  and  the  flight  crew  takes  control,  the  aircraft's 
mission  is  considered  started — even  before  the  aircraft 
physically  takes  off.  Thus,  if  the  aircraft's  mission  is 
aborted  after  the  flight  crew  takes  command,  the  aircraft 
reverts  to  the  post-flight  check.  This  is  true,  even  if  the 
aircraft  never  leaves  the  ground. 
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Figure  17.  A51,  Accomplish  Refuel/Rearm 


A51 ,  Determine  Refuel/Rearm  Sequence.  Since  these  are 
generally  mutually  exclusive  a*?titfj.ties,  the  rearm,  refuel 
sequence  must  be  determined  before  starting  either  to  rearm 
or  to  refuel.  If  only  refueling  or  rearming  are  required 
then  this  determination  step  may  be  skipped.  The 
determination  is  based  on  the  availability  of  the  refuel 
trucks,  rearmament  personnel  and  equipment. 

For  ground  refueling,  two  methods  are  primarily  used. 
On  larger  aircraft,  a  single  point  refueling  receptacle  is 
the  usual  refueling  method.  This  method  refuels  all  fuel 
tanks  on  the  aircraft  from  a  single  access  point.  However, 


A 
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smaller  aircraft  are  filled,  using  a  fuel  hose  with  a 
nozzle,  in  a  manner  similar  to  that  used  to  refuel 


automobiles . 

Each 

fuel  tank  must 

be 

filled  separately. 

through 

separate 

access 

points . 

The 

larger  aircraft  are 

able  to 

use 

this 

second 

method 

when 

the  single  point 

refueling  method  is  not  available.  This  can  be  accomplished 
since  each  fuel  tank  on  the  larger  aircraft  has  individual 
access  points,  as  well  as  the  single  access  point. 
Maintenance  personnel  know  the  method  for  refueling,  and  the 
type  of  fuel  for  each  aircraft  serviced  (this  information  is 
learned  from  the  TOs  and  technical  training). 

In  wartime,  as  long  as  bombs,  other  munitions,  and  the 
aircraft  to  carry  them  are  available,  the  aircraft  has  to  be 
resupplied.  Thus,  based  on  the  particular  aircraft,  and  its 
mission,  the  maintenance  personnel  know  whether  or  not  to 
contact  the  munitions  personnel  for  the  armaments  required. 


Appendix  B 


a/c 

aircraft 

aircraft-identification 

aircraf t-location 


aircraft -miss ion 

aircraf t-status 


=  A/C  =  aircraft 
=  the  physical,  individual 
aircraft.  Alias :  a/c,  A/C 
=  a/c- type  +  specif ic-a/c. 

Alias :  a/c-ID,  A/C-ID 

=  the  physical  location  of  the 
aircraft  including  its 

location  with  respect  to 
nearby  objects  of  interest. 
Alias :  a/c-location, 

A/C- location,  a/c-loc, 

A/C-loc 

*  what  the  aircraft  is 
scheduled  to  do  next.  Alias : 
a/c-mission,  A/C-mission 
=  current  state  (status)  of  the 
aircraft.  Possible  values 
(not  all  inclusive)j_ 

in -ground -maintenance, 
in -post -flight-check, 
flyable-a/c,  aircraft-parked, 
aircraf t-location. 


additional -ground-maintenance 


aircraft-type 


component 


compon  en  t - cond i t i on 


component-identification 


component -name 


required,  aircraft-secure, 
pre-f  light-check-complete. 
Alias :  a/c-status, 

A/C-status 

=  the  type  of  aircraft. 

Possible  values  (not  all 

inclusive  >2.  B52  bomber,  F4 

fighter,  KC135  tanker. 

Alias :  a/c-type,  A/C- type 

=  a  physical  item  or  part  on  or 
removable  from  the  aircraft. 
Alias:  comp 

=  the  current  state  of  each 
component  after  comparison  to 
the  technical  order 

requirements.  Alias: 
comp- cond 

=  a  unique  identifier  for  each 
component  which  denotes  which 
specific  aircraft  and  which 
particular  component  on  that 
aircraft.  Alias :  comp-ID 
=  the  name  of  the  component  as 
it  appears  on  checklists  and 
the  inventory  lists.  Alias: 


comp-name 


consumables 


diagnosis 


maintenance-hi story 


maintenance- reports 


mission-particular-resources 


ref uel/rearm-sequence 


=  those  items  which  are  needed 
for  each  and  every  aircraft, 
each  and  every  mission. 

=  what  is  thought  to  be  wrong 
with  a  component. 

=  the  record  of  maintenance  by 
part  and  malfunction  or 
intolerance  of  each  component 
and  aircraft.  Alias : 

maint-hist,  Maint-Hist 
=  those  reports  which 

maintenance  is  both  required 
and  requested  to  make  orally 
or  written.  Alias; 

maint-rep,  Maint-Rep 
=  those  items  which  are  needed 
by  an  aircraft  to  accomplish 
its  particular  mission. 
Alias :  M-P-Resources 
=  the  sequence  in  which 
rearmming  and  refueling  will 
be  accomplished;  since,  one 
may  only  be  done  after  the 
other  is  complete.  The  order 
does  not  matter.  Alias: 
refuel/rearm-sequence, 
ref uel/rearm-seq 


spares 


those  items  required  by 


maintenace  to  bring  the 
aircraft  and  its  components 
to  flyable  status. 

specific-aircraft  =  the  unique  aircraft  as 

identified  by  tail  number. 
Alias:  spec-a/c ,  spec-A/C, 
Spec-a/c,  Spee-A/C 

TO(s)  =  Air  Force  Technical  Order (s) 
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Appendix  C 


Audio  Cassette  Recorder  Programs 
(13  July  1982 :  Version  2.4) 

These  programs  were  modified  by  Roz  Taylor;  based  on  the 
original  programs  as  provided  in  the  MMD-l/MI  Operating 
Manual  by  E&L  Instruments,  Inc.  The  modifications  were 
necessary  to  use  the  MMD-l/MI  as  configured  at  AFIT. 

The  following  routines  were  used  with  the  MMD-1 
configured  with  the  Memory  Interface  Board.  Each  section  of 
code  starts  with  an  even  "octet".  When  the  code  is 
finalized,  the  trailing  NOPs  should  be  removed  and  the  total 
code  made  more  compact.  This  would  result  in  addresses 
being  changed  within  the  code.  It  was  deemed  at  this  time, 
unnecessary  to  accomplish  these  changes  prior  to  finalizing 
the  code.  The  code  which  follows  works,  but  may  not  be  the 
most  efficient  method. 

RAM  LOAD/DUMP  PROGRAM 

This  is  a  listing  of  the  Loader/Dump  Program  which  when 
resident,  is  located  in  the  main  board  RAM  (RAM  PR"2").  The 
PROM  LOAD/DUMP  PROGRAM  exists,  however  it  was  not  used 
because  the  PROM  location  interfered  with  the  special 
programming  installed  in  this  particular  version  of  the 


READ  FROM  CASSETTE  ROUTINE  ( RCAS ) :  This  routine  reads  the 
data  from  the  cassette  tape  and  stores  it  in  sucessive 
memory  locations  starting  with  030  000.  As  the  data  is 
input,  it  is  displayed  on  the  MMD-1  LEDs  (port  2).  The 
address  is  displayed  on  the  MMD-1  LEDs  via  ports  1  and  0. 
Control  is  returned  to  the  CRT  monitor  when  transfer  is 
complete.  START  CASSETTE  RECORDER  BEFORE  USING  THIS 
ROUTINE.  Modification  suggestion:  add  the  ability  for  user 
to  specify  number  of  blocks  of  code  to  be  moved  into  memory, 
as  in  the  write  to  cassette  routine. 


MEMORY 

CODE 

LABEL 

MNEMONIC  COMMENTS 

LOCATION 

002 

000 

041 

RCAS: 

LXIH 

Initialize  the  mem¬ 

002 

001 

000 

ory  pointer:  H=030 

002 

002 

030 

and  L=000. 

002 

003 

315 

CALL 

002 

004 

170 

INPUT 

002 

005 

002 

002 

006 

Thru 

002  010 

000 

NOP  (This  was  where 

a  previous 

bit  of  code 

was — but  eliminated. 

later ) 

002 

Oil 

333 

IN 

Clear  flags  if 

002 

012 

022 

necessary. 

002 

013 

315 

NEXTIN: 

CALL 

Input  a  byte  of 

002 

014 

100 

CASIN 

data  into  the 

002 

015 

002 

accumulator  from 

002 

016 

167 

the  cassette  tape. 

002 

017 

315 

CALL 

002 

020 

220 

DISPLAY 

002 

021 

002 

002 

022 

043 

INXH 

Increment  the  mem¬ 

002 

023 

174 

MOVAH 

ory  pointer,  load 

002 

024 

272 

CMPD 

new  high  address 

002 

025 

302 

JNZ 

value  and  check  for 

002 

026 

013 

NEXTIN 

end  of  loop.  If  not 

002 

027 

002 

end,  get  next  byte. 

002 

030 

303 

JMP 

When  done  loading 

002 

031 

240 

CRT 

return  to  the  CRT 

002 

032 

002 

monitor. 

002 

033 

thru 

002 

037 

000 

NOP 

121 
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WRITE  ONTO  CASSETTE  TAPE  ROUTINE  (WCAS) ;  This  routine 
stores  the  data  on  cassette  tape.  The  user  selects  from  1 
to  8  blocks  of  data.  Each  block  consists  of  377  (octal) 
bytes  of  memory,  starting  at  030  000.  Once  the  routine 
starts,  the  desired  number  of  blocks  is  entered  by  the  user 
via  the  HEX  pad  on  the  MMD-1 .  Use  0  to  indicate  8  blocks. 
After  a  22  second  delay,  the  data  is  written  onto  the 


cassette.  Once  the  data  is  written  to  tape,  control  is 
returned  to  the  CRT  monitor.  START  THE  CASSETTE  RECORDER 
BEFORE  USING  THIS  ROUTINE. 


002 

040 

041 

WCAS: 

LXIH 

Initialize  the  mem- 

002 

041 

000 

ory  point  to  H=030 

002 

042 

030 

and  L=000. 

002 

043 

315 

CALL 

Wait  for  user  to 

002 

044 

170 

INPUT 

input  number  of 

002 

045 

002 

bytes  to  be  trans- 

002 

046 

315 

CALL 

f erred.  Delays 

002 

047 

140 

DELAY 

the  start  of  the 

002 

050 

002 

data  transfer. 

002 

051 

Thru 

002  053 

000 

NOP  (Unnecessary  code 

removed ) 

002 

054 

176 

MORE: 

Get  data  from  mem- 

002 

055 

315 

CALL 

ory  (accumulator) 

002 

056 

120 

CAS  IN 

output  and  load  to 

002 

057 

002 

cassette  tape. 

002 

060 

315 

CALL 

Display  each  byte 

002 

061 

220 

DISPLAY 

data  and  its  add- 

002 

062 

002 

ress  on  ports  #2, 

1,  and  0 

002 

063 

043 

INXH 

respectively. 

002 

064 

174 

MOVAH 

Increment  the  high 

002 

065 

272 

CMPD 

address  byte  and 

002 

066 

302 

JNZ 

check  for  end  of 

002 

067 

054 

MORE 

data.  If  not  end. 

002 

070 

002 

get  more  data.  If 

002 

071 

303 

JMP 

end,  return  to  CRT 

002 

072 

240 

CRT 

monitor  routine. 

002 

073 

002 

002 

074 

Thru 

002  077 

000 

NOP 

122 


CASSETTE  INPUT  ROUTINE  (CASIN) :  This  routine  waits  for  data 
to  be  received  by  the  cassette  recorder  UART,  and  inputs  the 
data  into  the  accumulator. 


002 

100 

333 

CASIN: 

IN 

Check  the  cassette 

002 

101 

023 

UART  status  bits. 

002 

102 

037 

RAR 

002 

103 

322 

JNC 

Recheck  the  cassette 

002 

104 

100 

CASIN 

UART  status  bits 

002 

105 

002 

until  data  is  avail. 

002 

106 

333 

IN 

Input  data  to  the 

002 

107 

022 

accumulator . 

002 

110 

311 

RET 

Go  back  to  where 

002 

111 

000 

NOP 

CASIN  was  called. 

002 

112 

Thru  002  117 

000 

NOP 

123 
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"V 
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CASSETTE  OUTPUT  ROUTINE  (CASOUT) :  This  routine  waits  for 
the  transmitter  holding  register  to  say  it  is  ready  for  the 
next  data  byte.  The  routine  then  outputs  the  data  to  the 
cassette. 


002 

120 

365 

CASOUT:  PUSHPSW 

Save  the  data. 

002 

121 

333 

IN 

Check  the  transmit¬ 

002 

122 

023 

ter  status  bits. 

002 

123 

346 

AN  I 

002 

124 

004 

002 

125 

312 

JZ 

Recheck  the  trans¬ 

002 

126 

121 

CASOUT+1 

mitter  status  bits. 

002 

127 

002 

(But  do  NOT  try  to 

002 

130 

361 

POPPSW 

"resave"  the  prog 

002 

131 

323 

OUT 

status  word.) 

002 

132 

022 

Once  the  transmitter 

002 

133 

311 

RET 

status  says  it  is 

002 

134 

000 

NOP 

ready,  return  the 

002 

135 

000 

NOP 

data  to  the  ouput 

002 

136 

000 

NOP 

port  to  send  to  the 

002 

137 

000 

NOP 

cassette  recorder. 

124 


DELAY  PROGRAM  CONTINUATION  ROUTINE  (DELAY):  This  is  a  time 


delay.  As  programmed,  the  delay  is  for  about  22  seconds. 
If  the  value  ("001")  in  location  002  144  is  changed  to 
"000",  then  the  time  delay  is  only  about  12.2  seconds  (not 
quite  a  drop  by  half). 


002 

140 

365 

DELAY :  PUSHPSW 

Save  the  registers. 

002 

141 

305 

PUSHB 

002 

142 

001 

LX  IB 

Load  the  following 

002 

143 

364 

value  into  Reg.  B. 

002 

144 

001 

This  value  changes 

002 

145 

315 

CALL 

the  time  duration. 

002 

146 

277 

KTS 

KTS=THE  KEX  TIMEOUT 

002 

147 

000 

SUBROUTINE  (comes 

002 

150 

013 

DCXB 

with  the  MMD-1). 

002 

151 

170 

MOVAB 

When  count  is  not 

002 

152 

261 

ORAC 

zero,  recall  the 

002 

153 

302 

JNZ 

KTS.  (Do  NOT  do 

002 

154 

145 

DELAY +5 

all  those  saves/ 

002 

155 

002 

loads  again! ) 

002 

156 

301 

POPB 

When  time  is  up. 

002 

157 

361 

POPPSW 

restore  all  saved 

registers . 


002  160  311 

002  161  thru 


RET 

002  167  000 


NOP 


INPUT  NUMBER  OF  DATA  BLOCKS  TO  BE  MOVED  ROUTINE  (INPUT) : 
This  routine  allows  the  user  to  enter  a  single  digit  number 
from  the  HEX  keyboard  on  the  MMD-l/MI.  Only  the  numbers 
from  1  ->  8  are  accepted.  Use  a  "0"  to  denote  the  number  8. 
If  more  than  8  blocks  of  data  are  to  be  loaded  via  this 
method,  the  loading  routine  will  have  to  be  repeated  for 
each  set  of  8  or  less  blocks  with  appropriate  changes  in  the 
load  routine  to  allow  for  the  memory  location  differences. 


002 

170 

315 

INPUT: 

CALL 

002 

171 

315 

KEX 

002 

172 

000 

002 

173 

376 

CPI 

Check  for  a  number 

002 

174 

010 

from  0  ->  7,  input 

002 

175 

322 

JNC 

by  the  user. 

002 

176 

170 

INPUT 

If  not,  go  back  and 

002 

177 

002 

• 

try  again. 

002 

200 

267 

ORAA 

Set  flags. 

002 

201 

302 

JNZ 

002 

202 

206 

NOTO 

002 

203 

002 

002 

204 

306 

ADI 

Add  8,  if  the  zero 

002 

205 

010 

key  were  input. 

002 

206 

204 

NOTO: 

ADDH 

Compute  stopping 

002 

207 

127 

MOVDA 

address;  save  it 

002 

210 

311 

RET 

in  Reg.  D.  Go 

002 

211 

000 

NOP 

back  to  where 

002 

212 

000 

NOP 

called  from. 

002 

213  Thru 

002  217 

000 

NOP 

126 
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DISPLAY  CONTENTS  OF  MEMORY  ON  LEDS  ROUTINE  (DISPLAY) :  This 
routine  assumes  the  data  of  interest  (shown  by  contents  of  H 
&  L)  is  located  in  the  accumulator  when  it  is  called,  and 
displays  it  on  Port  2.  It  takes  the  address  given  in  H  &  L 
and  displays  them  on  Ports  1  &  0.  (Ports  2,  1,  &  0  are  LEDs 
on  the  MMD-1 . ) 


002 

220 

323 

DISPLAY:  OUT 

Move  the  contents  of 

002 

221 

002 

(Port  2) 

the  accumulator  to 

002 

222 

175 

MOVAL 

the  output  Port,  #2. 

002 

223 

323 

OUT 

Move  the  low  byte  of 

002 

224 

000 

(Port  0) 

the  address  to  output 

002 

225 

174 

MOVAH 

port,  #0,  and  the  high 

002 

226 

323 

OUT 

byte  of  the  address  to 

002 

227 

001 

output  port,  #1. 

002 

230 

311 

RET 

Go  back  to  who  called. 

002 

231 

Thru  002  237  000 

NOP 

*********************************************************** 

RETURN  CONTROL  TO  THE  CRT  MONITOR  ROUTINE  (CRT) ;  This 
routine  initializes  the  stack  pointer,  resets  he  MMD-1,  and 
returns  control  to  the  CRT  monitor  routine.  If  user  is 
concerned  about  resetting  to  the  beginning  of  the  Audio 
Cassette  Recorder  Programs,  change  program  contents  for  002 
244  and  002  245  to  the  starting  address  of  "free"  memory. 
002  244  is  the  low  byte  and  002  245  is  the  high  byte  of  the 
address . 


002 

240 

061 

CRT:  LX I 

Give  the  stack  pointer 

002 

241 

000 

SP 

the  value  4.  (i.e. 

002 

242 

004 

initialize  the  "SP".) 

002 

243 

041 

LXIH 

Load  the  starting  add¬ 

002 

244 

000 

ress  of  user  access¬ 

002 

245 

002 

ible  memory  into  H&L. 

This  is  equivalent  to 
using  the  RESET  button 
on  the  hex  pad  of  the 
MMD-1. 


002 

246 

176 

MOV  AM 

Move  the  contents  of 
the  addressed  memory 
location  into  the 
accumulator . 

002 

247 

315 

CALL 

Display  the  contents 
of  memory  on  the  MMD-1 

002 

250 

220 

DISPLAY 

LEDs. 

002 

251 

002 

002 

252 

303 

JMP 

Go  to  the  CRT  monitor 

002 

253 

000 

routine  (found  in  KEX 

002 

254 

001 

routines  in  MMD-1). 

002 

255  Thru 

002  257  000 

NOP 
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BOOTSTRAP  ROUTINE  ( BOOT ) :  This  routine  loads  the  previous 
code  (already  on  tape)  from  tape  into  the  memory  addresses 
given  above.  This  routine  must  be  entered,  by  hand,  each 
time  the  MMD-l/MI  unit  loses  power.  Unfortunately,  the 
MMD-1  does  NOT  have  continuous  memory.  NOTICE:  THIS 
ROUTINE  IS  LOADed  and  executed  from  HIGH  MEMORY!!!!!  Do  not 


tell  how  many  bytes  you  want  to  transfer.  When  all  MMD-1 


LED 

for 

lights  go 

more  than  5 

dark  for  more  than 

seconds,  the  tape  is 

5  seconds  or  all  are  li' 

through  loading. 

030 

000 

041 

BOOT:  LXIH 

Initialize  the  memory 

030 

001 

000 

pointer  to  starting 

030 

002 

002 

address  of  audio  cas- 

sette  Recorder 

Programs . 

030 

003 

333 

IN 

Clear  flags,  if 

030 

004 

022 

necessary. 

030 

005 

333 

NEXTIN:  IN 

Input  status  bits. 

030 

006 

023 

030 

007 

037 

RAR 

030 

010 

322 

JNC 

Jump  back  if  no  data 

030 

Oil 

005 

NEXTIN 

available,  yet. 

030 

012 

030 

030 

013 

333 

IN 

Input  data. 

030 

014 

022 

030 

015 

167 

MOVMA 

Store  the  data 

030 

016 

323 

OUT 

Output  the  data  and 

030 

017 

002 

address  to  Port  #2. 

030 

020 

175 

MOVAL 

Move  the  low  address 

030 

021 

323 

OUT 

byte  to  accumulator 

030 

022 

000 

and  output  to  Port  #0 

030 

023 

174 

MOVAH 

Move  the  high  address 

030 

024 

323 

OUT 

byte  to  the  accumula- 

030 

025 

001 

tor  and  display  on 

Port  #1. 

030 

026 

043 

INXH 

Increment  the  memory 

030 

027 

303 

JMP 

pointer  and  then  get 

030 

030 

005 

NEXTIN 

more  data. 

030 

031 

030 

129 


The  MMD-l/MI  Operating  Manual  lists  the  code  for  three 
routines  which  were  part  of  the  AFIT  K EX/MONITOR  adaptation. 
These  routines  were  TTYIN,  TTYOUT,  and  RDRIN.  These  were  at 
000  164,  and  000  201  respectively.  Since  RDRIN  was  for  a 
paper  tape  reader  input  subroutine  and  was  omitted  from  this 
work  as  unneeded.  It  was  not  included  in  the  AFIT 
modification  of  the  K EX/MON I TOR  program,  as  well. 
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Appendix  D 


List  of  Contacts  and  Suggested  Contacts 


Anderson,  Timothy.  He  works  at  the  Air  Force  Aerospace 
Medical  Research  Laboratory  (AFAMRL),  WPAFB,  Ohio.  He 
is  a  scientist/mathematician  interested  in  robotics. 
Extension:  513-255-4244. 

Bejczy,  Antal.  Manager,  Teleoperator  Laboratory,  NASA/JPL, 
Pasadena,  California. 

Braswell,  Robert  N  (Ph.D.).  Deputy  for  Armament  Systems, 
Armament  Division,  (AD/CZ),  Eglin  AFB,  FL  32542. 
AUTOVON:  872-5315. 

Brooks,  Fred  (Mr).  ASD/AIM,  WPAFB,  Ohio.  Required  to 
assess  robotics  and  its  impact  on  the  Air  Force.  1 
believe  he  had  to  write  a  statement  of  work  as  well. 

Chu,  Yee-yeen.  Senior  Scientist,  Perceptronics ,  Inc., 
Woodland  Hills,  California. 

CIMAR:  The  Center  for  Intelligent  Machines  and  Robotics. 

This  is  Dr.  Tesar's  group.  University  of  Florida,  300 
MEB,  Gainesville,  Florida  32611. 

Fielding,  Michael.  Program  Manager,  Airborne-Remotely- 
Operated  Devices,  Naval  Ocean  Systems  Center,  Kailua, 
Hawaii . 

Freedy,  Amos.  Executive  Vice  President,  Perceptronics, 
Inc.,  Woodland  Hills,  California. 

FTD  (Foreign  Technology  Division).  The  personnel  stationed 
at  FTD,  WPAFB  can  fill  (some)  requests  for  information 
searches  such  as  Unclassified  memorandums.  These 
memorandums  could  be  translations  of  "Moscow  Broadcast" 
taken  from  BBC  Summary  of  World  Broadcasts.  I 

discovered  this  prosepective  source  of  information 
through  Mr.  Tim  Anderson  (AFAMRL).  He  had  requested  a 
search  by  FTD  of  unclassified  information  relating  to 
robotics . 

Herbach  and  Rademan,  Inc.  401  East  Erie  Avenue, 

Philadelphia,  PA  19134  (215-426-1700).  This  was  where 
the  motors’  information  came  from. 

Hobby  Robot  Co.,  Inc.,  P.0.  Box  997,  Lilburn,  GA  30247. 
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Johnson,  R.  T.  Professor  at  University  of  Missouri-Rolla 
(was  the  Missouri  School  of  Mines).  He  is  involved  with 
the  fledgling  robotics  program  at  UM-R.  His  phone 
number  is  314-341-4614.  The  Department  of  Mechanical 
and  Aerospace  Engineering  Chairman's  phone  number  is 
314-341-4662,  while  the  general  faculty  phone  number  is 
314-341-4661.  The  address  is: 

Department  of  Mechanical  and  Aerospace  Engineering 
Mechanical  Engineering  Building 
Rolla,  MO  65401 

Dr.  Johnson  noted  in  a  letter  (to  me)  that  if  his 
"limited"  experience  would  benefit  me,  to  call. 

Kessler,  Bill.  A  Ph.D.  working  at  WPAFB,  Ohio  which  Dr. 
Tesar  suggested  as  someone  locally  to  talk  to  about 
robotics,  the  U  of  F,  and  Dr.  Tesar' s  work.  I  got  the 
impression  that  Dr.  Tesar  has  had  "dealings"  with  Dr. 
Kessler,  previously. 

Langendorf,  Lt.  Col.  Henry.  Chief,  AI/Robotics  Division, 
TRADOC,  Fort  Ben jamin-Harison,  Indiana. 

Lyman,  John.  Professor  and  Chairman,  Engineering  Systems 
Department,  School  of  Engineering  and  Applied  Science, 
UCLA.  "Professor  Lyman  has  participated  in  research, 
development  and  application  of  high-technology  robotic 
sysstems,  including  teleoperator  andd  limb  prosthetics, 
for  more  than  25  years.  His  special  interest  is  in  the 
human -equipment  interface  for  complex,  addaptive 

machines. " 

Madni,  Azad.  Director,  Robotics  and  Automation  Systems, 
Perceptronics ,  Inc.,  Woodland  Hills,  California.  "Dr. 
Madni  is  currently  principal  investigator  on  a  Navy 
Robotics  R&D  program  directed  toward  the  design  and 
development  of  an  intelligent  robotic  platform  for  U.S. 
Marine  Corps  reconnaissance  and  surveillance  needs.  He 
also  serves  as  an  advisor  to  the  U.S.  Army  Research 
Institute  Robotics/Artificial  Intelligence  Program.  Dr. 
Madni  has  been  principal  investigator  over  the  last  four 
years  on  several  DARPA  projects  in  man-machine 

relations,  user  models  in  information  prioritization  and 
selection  tasks,  advanced  methods  for  information 

display,  and  videodisc-based  low-cost  portable  training 
systems. " 

Mayer,  Lt  Gordon  E.  Lt  Mayer  is  the  Projects  Manager, 
Materials  Laboratory,  Wright-Patterson  AFB,  Ohio.  He 
has  his  M.S.  in  robotics  from  Purdue  University  (1979). 
His  thesis  was  on  the  Kinematic  Design/Control  of 
Manipulators.  He  worked  most  of  1979  for  Unimation 
prior  to  coming  on  active  duty  (Air  Force). 
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Montgomery,  Jerry  g.  Lt,  USAF.  Currently  assigned  to  ASD 
at  WPAFB,  Ohio.  Was  an  M.S.E.E.  student  in  pattern 
recognition  under  Dr.  Matthew  Kabrisky  at  AF1T.  He  is 
"local  expert"  on  fuzzy  set  theory  and  fuzzy  statistics. 
ASD/B1LE,  513-255-4044. 

Motors  (6-12V-DC).  These  motors  were  found  in  a  Brevel 
Stock  Motors  catalog.  These  were  purchased  from: 

Reserve  Electric, 

(Mike  Evans,  Sales  Engineer) 

2090  E.  19th  Ave, 

Cleveland,  Ohio 
216-771-5764 

RB  Robot  Corporation.  Produces  the  RB5X  robot  (with 
batteries  for  $1195.  "The  company  expects  computer  and 
electronics  engineers  and  hobbyists  to  buy  the  robot  as 
a  starter  system  for  further  robotics  development.  For 
$1195,  the  robot  you  get  is  blind,  deaf  and  dumb.  Its 
only  sensory  apparatuses  are  feely  bumpers  that  tell  it 
when  it  has  run  into  an  object.  They  provide  tactile 
input  for  the  robot's  learning  programs .... [ it ]  has  a 
standard  RS-232  serial  interf f ace. . . . [ it  has]  an  option 
package  with  sonar,  pulsating  light  and  extra  memory, 
for  $295"  (Infoworld,  1982).  The  company  is  located  in 
Golden,  Colorado. 

Roboticon.  Name  of  seminar  "series"  on  robotics.  Can  be 
offerred  "in-house".  For  more  information,  contact: 
Registrar,  Roboticon 
157  East  Valley  Parkway,  Suite  2B 
Escondido,  CA  92025 

Saveriano,  Jerry  W.  President,  Saveriano  &  Associates, 
Huntington  Beach,  California. 

Tallen,  Norman.  A  Ph.D.  working  at  WPAFB,  Ohio  which  Dr. 
Tesar  suggested  as  someone  locally  to  talk  to  about 
robotics,  the  U  of  F,  and  Dr.  Tesar' s  work.  I  got  the 
impression  that  Dr.  Tesar  has  had  "dealings"  with  Dr. 
Tallen,  previously. 

Tesar,  Delbert.  Director  of  CIMAR,  University  of  Florida, 
300  MEB,  Gainesville,  Florida  32611.  Dr.  Tesar  will 
usually  provide  copies  of  his  material  upon  request. 
904-392-0814  (He  was  also  quite  good  about  returning  my 
telephone  calls;  but,  I  tried  not  to  abuse  that  either!) 

UCLA  Extension.  A  short  course  program  was  offerred  at  UCLA 
on  11-14  January  1983,  entitled  "Smart  Systems  and  Human 
Factors  in  Battlefield  Robotics".  The  coordinators  and 
lecturers  were  John  Lyman  (PhD)  and  Azad  Madni  (PhD). 
Other  lecturers  were  Antal  Bejczy  (PhD),  Yee-yeen  Chu 
(PhD),  Michael  Fielding  (MS),  Amos  Freedy  (PhD),  Lt  Col. 
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Henry  Langendorf,  and  Jerry  W.  Saver iano  (MS).  Each  of 
these  lecturers  and  their  "addresses"  are  listed 
separately.  This  was  a  four  day  course,  EDP  No.  E4719V, 
Course  No.  Engineering  839.42,  2.4  CEU.  Mailing  list 

address  is: 

Mailing  Lists,  UCLA  Extensions 

P.0.  Box  24901 

Los  Angeles,  CA  90024 

Perhaps  lecture  notes  or  other  information  would  be 
available,  if  requested.  The  intent  (quoted  from  the 
mailing  list  brochure)  was  "for  managers  of 
robotics/automation  programs,  developers  of  advanced 
weapon  systems,  researchers  in  the  field  of  intelligent 
automation,  C3  system  designers  and  human  factors 
engineers."  The  purpose  "provides  new  concepts, 
methodologies,  and  specific  technologies  which  are 
directly  applicable  to  the  development  and  realization 
of  smart  weapon  systems  for  1990-2000  time  frame.  It 
introduces  generic  approaches  that  should  allow  system 
developers  to  meaningfully  apply  state-of-the-art 
techniques  in  human  factors  engineering  and  man-machine 
interface  design,  advanced  automation  and  expert 
systems,  user  models  and  information  management  aids  to 
various  current  and  projected  application  areas  in 
battlefield  robotics. 
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DC  Gear-motor  Specifications 
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The  MR  DC  Geeimotor  •»  used  where  low  to  med.um 
speed  opei  ation  and  high  torque  tie  desired  It  n  (/tn>cvi*Hy 
Suited  IO  applications  requiring  high  Starling  torque.  infinitely 
variable  spired  Control  t'HJ  ck  reversibility  7 yp.caf  appi>ca 
t  ons  include  amusement  g^mei.  business  machines.  rmciO 


bins  transports,  tape  duvet,  doot  o>  drawer  Openers,  vending 
machine*.  and  many  others  Where  othei  features  o»  perform 
ance  arc  required  «*f  w.ti  design  to  su>t  trie  application  and 
furnish  a  quotation  after  complete  specifications  are  received 


mechanical  construction 

GEAR  CASE  Gears  fully  enclosed  m  heavily  reinforced, 
closely  filling  imc  alloy  d*e  castings 

BEARINGS  Output  and  At  mature  Bear  mgs  arc  pre  -o-ied. 
Sintered  metal  Armature  Bearings  are  sell  aligning  with 
large  0-1  reservoirs  Intermediate  gears  turn  on  ha'Oenad 
and  ground  Heel  pms  securely  held  m  die  castings 

GEARING  Helical  rotor  Pinion  and  henca’  imen  base  pheno 
fic  first  gear  for  nurse  reduction  is  standard  Spur  gears  and 
pinions  aie  used  m  other  stages  Gears  and  Pinion*  are 
hardened  to  suit  the  application  Number  of  sieges  be 
tween  rotor  pinion  and  final  gear  will  vary  according  to 
output  speed 

OUTPUT  SHAFT  Casa  hardened  cold  rolled  steel.  V*  die  . 

V  long  is  standard 

BRUSHES  Copper  Graphite  with  Co>l  Springs  is  standard 
Brush  replaceable  without  disassembling  motor. 

FAN  SHAFT:  Rear  motor  tateniton  0f  .1818"  Oia 

MOUNTING  Four  *8  32  Tap  thru  holes  standard 

All  specifications  subiect  to  changa  without  notice. 

V _ _ _ 


ENGINEERING  DATA 
SPEED  RANGE  0  5  to  400  R  P  M 

TOROUE  Up  to  75  lb  rr>  higher  available  depending  upon 
duty  cycle 

ELECTRICAL  SPECIFICATIONS 
SUPPLY  VOLTAGE  6  0  to  48  Volts 
TERMINALS  3/16  Male  Quick  Connectors 

OPTIONAL  FEATURES 

•  Mounting  Configuration  Four  Holes  103?.  1/4  20  Tap 

pr.  170  Thru 

•  Electrical  Terminations  1 10  Wide  Male  Qu>cfc  Connect 

Terminals  or  Leads  to  Suit 

•  Tachometer  Output  0  C  Voltage  Proportional  to  Speed 

•  Output  Shad  Configuration.  Up  to  3/8"  0  D  with  Flats. 

Ciossdnlied  Holes,  Internal  or  External  Threads.  Rea> 
Ekttnsion.  or  Other  Features  to  Sun  Stainless  Steti 
Materia'  and  Other  Corrosion  Protection  Available 

•  Refer  10  Engineering  Bulletin  No  40  for  additional 

features  available  on  the  drive  motof. 
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THE  designs  shown  on  THIS  page  are 
READILY  AVAILABLE  FROM  STOCK. 


SPECIAL  DESIGNS  CAN  BE  ENGINEERED 
TO  MEET  YOUR  SPECIFIC  APPLICATION 


V. 


BREVEL  MOTORS  INC. 

•  subsidiary  of 

(j?)  VERNITRON  CORPORATION 


BROAD  AND  16ih  STREETS 
CARiSTADT.  NEW  JERSEY  0?0>? 
TELEPHONE  (201 1  S33  0220 
TELEX  6A2-606 
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